Re: Workaround for system upgrade bug suggestions

[Barry Scott <barry@xxxxxxxxxxxxxxxx>]

> On 3 Nov 2020, at 15:00, Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote:
> 
> On Mo, 02.11.20 22:20, Barry (barry@xxxxxxxxxxxxxxxx) 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

_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel