On Thu 25 Oct, 11:02 -0400, Daniel Kahn Gillmor <d...@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
