found 743743 2.88dsf-59.2 retitle 743743 initscripts: bootmisc.sh not using /run/nologin locks users out after reboot severity 743743 important tags 743743 + patch thanks
My system, after a couple years of uptime, unexpectedly rebooted. It had a symlink from /etc/nologin to /var/lib/initscripts/nologin last modified in 2011, which I never manually set up. When trying to recover my system after that incident, logging in through SSH, I was greeted by the nice message: "System bootup in progress - please wait", in a permanent fashion. I was locked out, apart from physically logging in as root. When I managed to do so, I realized that the boot sequence had ended fine, but as mentioned before, a combination of uncertain /etc/nologin symlink management and discrepancies between bootmisc.sh and other users made it so that I lost access after the reboot for no good reason. I was very much not pleased. This is arguably worse than the /etc/nologin feature just occasionally failing to prevent access. Let me reiterate that I never manually fiddled with that configuration, it just somehow ended in that state through updates. I really see no reason why /etc/init.d/bootmisc.sh should use /var/lib/initscripts/nologin or a location that isn't even under /run or /var/run when it clearly belongs there. So can we please apply the patch above or equivalent? Please note that some postinst should really clean up that /var/lib/initscripts/nologin because it still won't delete itself at the next reboot either (and the stray /var/lib/initscripts/ directory could be removed too then I suppose). In some cases, like mine, the /etc/nologin symlink will be left pointing to that pointless location, so it would be nice if that could be fixed too, but I have no idea how this is supposed to work. At least people won't get unexpectedly locked out anymore. Please take a step to fix this long-standing mess :/ Best regards, -- Pierre Ynard "Une âme dans un corps, c'est comme un dessin sur une feuille de papier."
