Hacker News Reader

Comment by telmich | Hacker News Reader

Regarding not rebooting: sometimes systemd hangs and does not reboot in our setups, but we were never able to sufficiently debug this, as all terminals are already gone and it seems that systemds is waiting in a loop for dependencies that don't solve.

View on HN

Oh, somebody else has this problem. It is random for you, too? Like, reboot 45 machines, 1 hangs. Completely inconsistent.

Have you tried passing 'debug' instead of 'quiet splash' to the kernel cmdline and doing halt instead of poweroff/reboot? That way you should see what's going on during shutdown.

In terms of booting: we are aware that systemd just kills fsck after a timeout. And that you can adjust the timeout. It is just something additional that we need to take care of, when running a system with systemd that is not the expected behaviour of a Linux system (like: why would you ever want to abort fsck?)

If you have a large (multi TB) filesystem, sometimes those can take a long time to fsck.

And if the fsck is just a scheduled one (after x reboots) instead of being triggered due to filesystem weirdness, then getting the server back up and serving can be the higher priority.

That's just an example because you asked though. Wouldn't want that same fsck to be skipped if it was actually started due to filesystem weirdness being detected. :)

And re halt/poweroff/reboot: We tried to figure it out for some systems, where a user session was blocking reboot, but eventually stopped investing resources into it. Similar to the booting problem, we expect a computer to "just reboot" and the default behaviour should be that kill -9 is issued after some timeout.

Reply on news.ycombinator.com