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. >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 _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel