Debian reconsiders init-system diversity

yes, they do.

That's why it pisses me off that on some of my servers running systemd, it can take tens of minutes - or longer - to shutdown or reboot.

It often goes into a seemingly endless wait-loop - I say "seemingly" because I don't have hours or days to wait for the machine to finish shutdown and reboot, and frequently have to just physically power-cycle the machine just so I can reboot it sometime today rather than tomorrow. or next year.

And "hours" is NOT an exaggeration - I have occasionally left machines in that wait-loop state for half a day or a day just to see if it will eventually give up and reboot like I told it to. That patience is not rewarded, the wait is only resolved with a power cycle.

I have NFI why it does that, but if I watch the console while a server is shutting down, I see systemd repeatedly increasing the timeout while it's waiting for something (like stopping a service or unmounting a filesystem or de-configuring a network interface) to stop. and for each repeat it increases the timeout - from tens of seconds to several minutes to tens of minutes and even hours.

why even bother having a timeout on a stop action if you're just going to repeat the wait with an ever-increasing timeout?

I **never** had that problem with sysvinit. My machines still running sysvinit give everything a reasonable timeout to stop cleanly - and then reboot anyway. Which is **exactly** what a server **should** do when an zombie process or whatever won't die - otherwise it'll get stuck waiting forever.

in my experience, systemd does not cope well with error conditions and takes ages to either boot up, shutdown, or reboot if there are any problems - especially with drives or networks. and when shit like that happens, that's exactly the time you want the machine to reboot quickly so you can find the problem and fix it. not wait 10s of minutes or hours for every reboot.

if everything goes well, systemd can boot up in 5 seconds rather than 15. amazing! that's really worth writing home about. if not, systemd might finish booting in hours rather than seconds.

---

And booting up with systemd is no better - on one of my machines, booting it will sometimes trigger an endless (?) loop of adding the same half-dozen routes to the routing table, ending up with MILLIONS of copies of the same half-dozen routes in the routing table (as shown by "ip route list > ip-route-list.txt" - the last time I tried that, ip-route-list.txt was over 15 million lines long...and it was only that "short" because I got bored of waiting for "ip route list" to finish, and hit ^C to kill it). e.g.

# wc -l /root/ip-route-list.txt
15426932 /root/ip-route-list.txt

To stop it, I have to login on the console, down the interface(s), and then manually bring them back up again. and then I have to manually restart the services that were bound to specific IP addresses (such as the ones I only want listening on an internal LAN address rather than a live internet address. The ones that listen on all addresses generally didn't need to be manually restarted). Obviously, this is a completely shit thing to have to do on a server - it's supposed to boot up and start providing its services without manual intervention.

Again, I have NFI why that happens. Neither systemd-analyse nor systemctl status nor journalctl have any useful information to offer.

At least with sysvinit i'd be able to find out which script had a broken loop. At worst, i could add debugging printf statements in likely-suspect scripts. with systemd, it just does what it wants to do when it wants to do it and fuck you if you want to find out why or, cthulhu forbid, override it.

I've got to the point with this infuriating bug that I'm going to P2V clone the entire system into a VM so that I can experiment enough to find out WTF is going on without having my server down for days on end. I'll be able to reboot the VM as often as I need without disturbing the other machines that depend on the services it provides (NFS, DNS cache, dhcpd, squid proxy, and more).

my current guess is that it'll probably turn out to be some stupid race condition - but I don't know where or what's causing it.

and on another of my machines (my mythtv box at home), it boots perfectly with sysvinit but whenever I try to boot it with systemd it fails to boot at all. every single time.