4 ms·
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 alre
by telmich 9y ago
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.
- moreentropy 9y agoHave 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 agoIn 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 agoIf 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 agoAnd 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.
- yjftsjthsd-h 9y agoOh, somebody else has this problem. It is random for you, too? Like, reboot 45 machines, 1 hangs. Completely inconsistent.