Hacker News Reader

Comment by majewsky | Hacker News Reader

> We tried to build Data Center Light on Debian and Ubuntu, but servers that don't boot, that don't reboot or systemd-resolved that constantly interferes with our core network configuration made it too expensive to run Debian or Ubuntu.

Can you expand on that? I work at a cloud provider, and I never heard of such issues before. Our default images are Ubuntu 16.04, RHEL 7 and SLES 12, so systemd all around.

View on HN

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.

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.

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

Sure. With huge storage arrays, fsck might take a long time. systemd by defaults aborts after some time and will not mount that array.

So your file system check is killed and leaves your array in a possibly corrupt state? That is simply insane.

Did you file that in the systemd issue tracker? I had a quick look and couldn't see a report there: https://github.com/systemd/systemd/issues?utf8=%E2%9C%93&q=i...

This could be an honest mistake. On my system, systemd-fsck-root.service and systemd-fsck@.service have `TimeoutSec = 0`, which I guess to mean "no timeout", but the systemd-fsck executable could have its own timeout. In any case, filing a bugreport sounds much easier than switching distributions.

And regarding networking: one very simple, obvious non-feature is that search paths from radvd or dhcpd are not correctly passed on to the OS processes, which breaks resolving server names.

Could you detail that?

Reply on news.ycombinator.com