Stale /var/run/nologin

Sam Varshavchik mrsam at courier-mta.com
Sun Jan 5 03:35:12 UTC 2014


Steven Ulrick writes:

> On Saturday, January 4, 2014, Sam Varshavchik <<URL:mailto:mrsam at courier- 
> mta.com>mrsam at courier-mta.com> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20140104/23488ce7/attachment.sig>


More information about the users mailing list