> you are not listening or being are deliberately obtuse

Any time you find yourself writing something like that, ask whether you’ve done a good job explaining your point first. In this case, you’ve been vague about everything except that you think systemd is the source of your non-deterministic behavior.

From what little information you’ve provided, it really sounds like the problem is a combination of blaming the init system for things which happen outside of it (i.e. processes hanging) and not learning how to use it. For example, launching a networked process under cron at boot with no retry mechanism has always been a problem because cron never guaranteed networking. Using the init system would have avoided that - even on SysV.

As far as how to discover it goes, fault tolerance has lots of edge cases — e.g. try mounting NFS and firewalling the server, `kill -STOP` a daemon with a clean shutdown process, reboot without a network or DNS (i.e. like you’d have during a facilities outage), etc. — but most of it comes down to learning to work with the way the distribution is intended to be used: use the init system (whatever it is) to launch processes, enable automatic restarts for everything, configure full dependencies on everything you need, etc.

Note that none of that depends on systemd - you can get better results on everything this way, but if you do it you’ll probably gain a better understanding the systemd developers made the choices they did. If you really can’t figure out how to be comfortable with it, switching to a distribution which doesn’t use it will be much better than fighting it and getting angry when the developers don’t support hammering a screw.

Suppose you run your system on a new, better, and faster computer architecture, newly supported by Linux. Now, let’s assume that this is a new architechure which in many ways is different in style to other processors, but let’s say GCC supports it and can generate 100% correct code from it. Your problem now is that much of all the old software was written and tested only on older architectures, and this new architecture exposes many bugs such as previously unknown reliance on undefined behavior, which worked on all old architectures, but not this new one.

Now. Do you blame the new architecture for this bad situation? Or do you blame the old software, which technically always had bugs but those bugs were previously not triggered?

The harder it is to avoid undefined behavior, the more I blame things other than the software. Especially when you can run the old version under emulation and it still works without bugs.

And a lot of the blame goes to the distro that shipped a bunch of broken binaries.

> The harder it is to avoid undefined behavior

That is surely an aspect of the language, not the platform?

> And a lot of the blame goes to the distro that shipped a bunch of broken binaries.

Sure, I can see that. It is normally the case with new ports to new platforms to be in a state of unreadiness for quite a while. But this is not really relevant to the question of who to blame for the brokenness; the hardware platform or the software?

My analogy is that systemd merely exposed bugs in other software which had been there for ages (and only sporadically exposed). But then systemd comes along and expose a whole lot of them at once. Keeping with the analogy, some blame certainly goes to any disto which released this combination of systemd plus software which has bugs triggered by systemd, but still, is it reasonable to blame systemd in this case?