[systemd-devel] Workaround for system upgrade bug suggestions
Barry Scott
barry at barrys-emacs.org
Tue Nov 3 16:25:20 UTC 2020
> On 3 Nov 2020, at 15:00, Lennart Poettering <lennart at poettering.net> wrote:
>
> 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.
I'm seeing this with Fedora. First on upgrade from 30 to 31
then upgrade from 31 to 32.
Does the journalctl output that I put on the bug report give any clues?
If not what should I hunt for in the journal to help?
I think I still have the journal from the last upgrade.
>
>> 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.
Barry
More information about the systemd-devel
mailing list