[pkg-gnupg-maint] Bug#911768: Bug#911768: pinentry-gnome3 fails to open a window with 'No Gcr System Prompter available, falling back to curses'

[Tiziano Zito]

On Thu 25 Oct, 11:02 -0400, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
>On Thu 2018-10-25 13:03:12 +0200, Tiziano Zito wrote:
>> It has nothing to do with pinentry. Given that I have a system with almost
>> identical setup without dbus-user-session where everything works, and given that
>> installing dbus-user-session in the affected system fixed the issue, I started
>> digging deeper.
>
>I'm glad to hear that installing dbus-user-session fixed the issue.  I'm
>inclined to make dbus-user-session a hard Depends: of pinentry-gnome3
>instead of a Recommends: to avoid future problems like this.  What would
>you think of that change?

I think it's probably a good idea, but, as I said, I have a setup where it works 
without dbus-user-session, so it is indeed not strictly required.

>> For the record, in case in the future anyone hits the same problem: The only
>> difference between the affected system and the working one was that the affected
>> system starts nfs-kernel-server.service on boot. This was not only delaying the
>> boot process (whish is somewhat expected) but additionaly the order changed in
>> which systemd services were started, resulting in a different order than the one
>> in the working system. I couldn't pin down exactly what service was the
>> problematic one, but disabling the nfs-kernel-server.service fixed the pinentry
>> issue...
>
>this is strange to me, because i think nfs-kernel-server.service is a
>system service, and gpg-agent.{service,socket} (from the gpg-agent
>package) and dbus.{service,socket} (from the dbus-user-session package)
>are user services -- they shouldn't have any direct interaction, and
>they're actually managed by entirely different systemd instances.

I was puzzled as you are. I think the issue is probably deeper than that, in the 
sense that it could be that the nfs-kernel-service was delayed by something 
else. But there is a connection between the dbus service and nfs-kernel-server. 
On my system at least I see this:

# systemctl list-dependencies --before nfs-kernel-server.service
nfs-kernel-server.service
● ├─rpc-statd-notify.service
● └─remote-fs-pre.target
●   ├─remote-fs.target
●   │ ├─acpi-support.service
●   │ ├─cpufrequtils.service
●   │ ├─cron.service
●   │ ├─gpm.service
●   │ ├─libvirtd.service
●   │ ├─loadcpufreq.service
●   │ └─systemd-user-sessions.service
●   └─shutdown.target

Isn't systemd-user-sessions used when the user starts a X session? If 
I understand it correctly, when the users starts a X session, a dbus-daemon is 
launched for her. Could it be that the dbus-daemon couldn't start because it was 
waiting for nfs-kernel-server, but gpg-agent, being started by systemd directly, 
got started too soon?

As I said, that's total speculation, and I am not really up for fiddling with 
the system to reproduce the bug again. We both spent too much time with this 
problem, which is probably due to my very special setup.

>At any rate, i'm glad to hear that dbus-user-session fixed the issue for
>you!  do you have any reason that you don't want to just leave it
>installed?

Oh, no reason more than "why should I install one additional package when on 
another almost identical system it works even without?". Not a very compelling 
reason, I agree :)))

Thank you for your patience ;)

Tiziano