Steven Ulrick writes:
On Saturday, January 4, 2014, Sam Varshavchik <<URL:mailto:mrsam@courier- mta.com>mrsam@xxxxxxxxxxxxxxx> wrote: > About ten hours after a reboot, a chance attempt to log in back to the server was rather rudely rejected with a:> > System is booting up. See pam_nologin(8) > Connection closed by 192.168.0.2 >> A quick run back to the console revealed the existence of a ten hour old /var/run/nologin file as the culprit. Removing it put everything back in working order.Two things: 1. You are not alone! 2. Thanks for the workaround...
I yearn for the days of /etc/rc.d. If something strange was going on during system boot, a carefully crafted grep inevitably digs up a bunch of scripts to sift through for the answers.
Now, there's all kinds of flotsam all over the place. Unpredictable, non- deterministic things running in different order. Has anyone actually bothered to look at all the ugly spew on the console, during system boot? systemd barfing all over the place, whining about having to break circular dependencies, multiple times, or not finding some godforsaken socket, somewhere? It's a miracle that a stable system eventually comes up at all, after all that.
systemd is crap.If this were the old days, I'd say that I'd have pretty good odds at knowing where to look simply by executing grep /var/run/nologin /etc/rc*.d/*, or maybe grep nologin /etc/rc*.d.*. I say odds are pretty good that this will find a script or scripts that monkey around with nologin, so I can start figuring out why it was created, or why wasn't it removed, at system boot.
Anyway, after Googling around, I found that this is bug 1043212, and reading that bug wasn't very confidence-inspiring. It seems that:
1) Running systemd-tmpfiles --create fubars a running system. Ok.2) So the working theory was that something must be spuriously executing systemd-tmpfiles. Noone has any idea what's doing that, and noone has any idea how to even figure out what it is.
3) But there does not seem to be any actual evidence that something is really executing systemd-tmpfiles in error. But, since doing that creates /run/nologin, that has to be what's happening, right? The thought that, maybe, the bug is really a failure to remove /run/nologin when the system entered multiuser state, apparently hasn't occured to anyone.
4) But instead of chasing down what's executing systemd-tmpfiles and proving this theory, here's a great idea: introduce more command line options and more configuration settings. Spray out a patch that changes what systemd- tmpfiles --create does by default, and, instead, introduce a new option to have systemd-tmpfiles do what it does now, with the --create option.
Sounds …great. Sure hope everyone's right, and that will "fix" this bug. It sure would be a shame that after all that said and done, … /run/nologin still exists. Because the bug really turned out to be in systemd-user- sessions, that, my digging found to be the actual part of systemd's jigsaw puzzle that's supposed to be responsible for removing it.
Duly noted.
Attachment:
pgptbnGGu6vZ6.pgp
Description: PGP signature
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
