[systemd-devel] Workaround for system upgrade bug suggestions

Lennart Poettering lennart at poettering.net
Tue Nov 3 15:00:39 UTC 2020


On Mo, 02.11.20 22:20, Barry (barry at barrys-emacs.org) wrote:

> What is the work around until the bug is fixed?

First step is to understand the bug. I still don't.

At very early boot-up systemd-tmpfiles.service creates the file
/run/nologin, which the PAM module pam_nologin.so checks for, and if
it exists it will deny login attempts. During regular boots this file
is removed by "systemd-user-sessions.service" which runs much later
during boot: right before gdm is started, but after logind, after
/home is started, after all network file systems are mounted.

The file thus ensures that users definitely cannot log in while the
system is still in the process of booting up.

Normally, I'd assume that systemd-user-sessions.service is not pulled
in during system update boots. The question is, is it pulled in
anyway? From upstream it's pulled in by multi-user.target, and that
shouldn't end up in the system upgrade boot mode. But I have no idea
what your distros offline update logic precisely puts into its initial
transaction.

Or maybe on your distro pam_nologin.so is missing from the PAM stack
that systemd --user is invoked through, i.e. from
/etc/pam.d/system-user. Can you check if it's there? (And any includes
referenced therein)? If so, the existance of /run/nologin of course
won't block the systemd --user instance.

>From upstream we only provide a very minimal PAM stack by default,
downstreams likely have to patch it, since they generalize parts of
the stack in include files, but they all do it differently, hence we
can't really carry that upstream.

Lennart

--
Lennart Poettering, Berlin


More information about the systemd-devel mailing list