3 ms·

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 o

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.

telmich 9y ago
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?)
- deleted 9y ago
  [deleted]
- justinclift 9y ago
  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. :)
telmich 9y ago
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.