Control: reassign -1 pinentry-gnome3 1.1.0-1
Control: affects -1 nfs-kernel-server gcr
I think this should be considered to be a pinentry-gnome3 bug rather than
nfs-kernel-server. I think the plausible routes forward are to either
escalate dbus-user-session from Recommends to Depends, downgrade this bug
to non-RC (because not working completely reliably without Recommends is
not entirely unexpected), or consider it to be "not a bug" and close it
(same reason).
It's a pity we can't make pinentry-gnome3 depend on something like
"dbus-user-session | not(libpam-systemd)".
On Fri, 26 Oct 2018 at 01:07:46 +0200, Tiziano Zito wrote:
> On Thu 25 Oct, 11:02 -0400, Daniel Kahn Gillmor <d...@fifthhorseman.net>
> wrote:
> > I'm
> > inclined to make dbus-user-session a hard Depends: of pinentry-gnome3
> > instead of a Recommends: to avoid future problems like this.
>
> 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.
pinentry-gnome3 is presumably a D-Bus client that wants to communicate
with the D-Bus service in gcr (which pops up a GNOME Shell system-modal
dialog if you're running a full GNOME environment, or an ordinary X11
window with appropriate grabs and other magic otherwise), falling back
to curses if it can't.
As a dbus upstream and Debian maintainer, I'd recommend installing
dbus-user-session, particularly if you have bits of infrastructure that
want to run one instance per (machine,uid) pair (typically user-services
started by `systemd --user`) and communicate via D-Bus.
In more opinionated distributions like Fedora and Arch Linux, the
equivalent of our dbus-user-session package is integrated into the
equivalent of our dbus package and is not straightforward to disable. In
Debian, you can still use dbus-x11 as an alternative to dbus-user-session
if you are relying on a separate D-Bus session bus per X11 display
(this is sometimes necessary if you are trying to preserve a workflow
involving remote displays, but is not going to work well with per-user
services that want to communicate via D-Bus) or if you don't like systemd.
In the dbus-x11 code path, code in /etc/X11/Xsession.d tries to tell
`systemd --user` where to find the most-recently-started X11 DISPLAY and
D-Bus DBUS_SESSION_BUS_ADDRESS by adding those environment variables
to the environment to be used for newly-launched services, but this
is not necessarily 100% reliable, and anything that `systemd --user`
already started cannot retroactively inherit those environment variables.
pinentry-gnome3 is not directly a user service, but it's run by gpg-agent,
which is a user service (at least on systemd systems).
> > 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
Correct. System services are configured in
{/lib,/etc,/run}/systemd/system and started by pid 1.
User services are configured in
{/usr/lib,/etc,~/.local/share,~/.config}/systemd/user and started by a
`systemd --user` process owned by the appropriate uid, which is itself
a system service.
> Isn't systemd-user-sessions used when the user starts a X session?
Not exactly. The Description of systemd-user-sessions.service is "Permit
User Sessions": it's the service that creates and deletes /run/nologin,
which controls pam_nologin, at the appropriate point in the boot process.
Anything that needs to happen before users can be allowed to
log in (e.g. mounting all filesystems) should be ordered Before
systemd-user-sessions.service. Anything that lets users log in (getty,
xdm/gdm/etc., sshd) can start up before systemd-user-sessions.service if
it wants to improve perceived startup speed, but won't be practically
useful at that point, since logins are not going to succeed before
systemd-user-sessions.service has run in any case.
> If I
> understand it correctly, when the users starts a X session, a dbus-daemon is
> launched for her.
This functionality is provided by the default-dbus-session-bus
and dbus-session-bus virtual packages, and there are two concrete
implementations: dbus-user-session (the default on Linux) and dbus-x11
(an alternative on Linux, and the only implementation on non-Linux
kernels or pre-stretch Debian releases).
In the dbus-user-session code path, this is done because pam_systemd tells
systemd-logind when a login session is opened or closed. On the transition
from 0 to 1 login sessions for (for example) uid 1000, systemd-logind starts
the user@1000.service system service. On the transition from 1 to 0 login
sessions for uid 1000, systemd-logind stops user@1000.service.
user@1000.service represents a `systemd --user` process running as uid
1000, which launches "user services" for uid 1000, as configured in
{/usr/lib,/etc,~/.local/share,~/.config}/systemd/user. If
dbus-user-session is installed, one of those per-user services is
`dbus-daemon --session`.
In the dbus-x11 code path, `systemd --user` might still be running (if you
happen to have libpam-systemd) but it doesn't know about a user service
to run dbus-daemon. Instead, /etc/X11/Xsession.d/75dbus_dbus-launch
runs a new `dbus-launch --exit-with-session` process per X11 display,
which starts a `dbus-daemon --session` process per X11 display.
/etc/X11/Xsession.d/95dbus_update-activation-env forwards some relevant
environment variables to `systemd --user` (if it's running) so that
subsequently-started systemd user services will inherit them.
> 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?
It seems plausible that gpg-agent might have started before
/etc/X11/Xsession.d got far enough to tell `systemd --user` that next time
it starts a user service, it should inherit the DISPLAY and
DBUS_SESSION_BUS_ADDRESS that will let it communicate with the
`dbus-daemon --session` that would let it communicate with gcr.
> > 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?".
dbus-user-session is entirely "glue" and doesn't contain significant
amounts of code. Depending how other packages' dependencies are set up
and how much progress has been made on fixing my 2016 mass-bug-filing
about dbus-launch (dbus-x11), installing dbus-user-session might let
you remove dbus-x11, which is larger than dbus-user-session. Is that
any help? :-)
On Fri, 21 Dec 2018 at 10:55:53 -0500, Daniel Kahn Gillmor wrote:
> On Fri 2018-12-21 07:28:22 -0500, Theodore Y. Ts'o wrote:
> > The next experiment to do would be to reinstall nfs-kernel-server and
> > reboot --- and see if it falls back to curses again.
For what it's worth, I couldn't reproduce this bug by installing a fairly
minimal GUI system (xdm, xorg and openbox) plus pinentry-gnome3 and
gpg-agent in a test VM, purging dbus-user-session, and adding and
removing nfs-kernel-server.
Regards,
smcv
at the Cambridge BSP
