| > If you want a dedicated supervisor, you can use something explicitly designed for such a purpose, like monit or supervisord, instead of using systemd's mixed functionality. Without being pid 1, that dedicated supervisor needs supervision. Now you have duplicated functionality. At the same time, said supervisor runs into all kinds of extra problems to ensure proper cleanup of misbehaving services. Supervisord for example is a perfect example of a process monitor is easy to make lose track of the services it's supposed to monitor (I'm not trusting it again). Systemd's use of cgroups for this is for good reason: it's a hard problem to sort out. You may end up with something usable, but a lot of the Systemd decisions are the ways they are because the alternatives were severely broken. And yes, that includes supervisord and monit. E.g. here's an example from the Monit website: check process apache with pidfile /var/run/httpd.pid
start program = "/etc/init.d/apache2 start"
stop program = "/etc/init.d/apache2 stop"
This seems innocent enough. Certainly it's better than "just" plain old SysV init. But it is still fundamentally broken.I've lost count of the number of times the Apache init scripts fails to bring Apache reliably up or down, for a variety of reasons, and the assumption that the pid-file will actually contain the pid of Apache or an invalid pid is fundamentally broken (the number of times I've found the pid-space has rolled over quickly enough to cause problems? Not huge, but far from zero), as is the assumption that there won't be other Apache processes in various unpleasant states whose pid is not in the pid file, but which will prevent a restart. The problem is that Monit is fairly representative for process managers in this respect, most of which makes the (broken) assumption that the init scripts start, stop and restart actions will work reliably, and/or that the pid file contains sane content, and/or that you have a reliable way to kill a process based on holding onto a pid. I've yet to encounter a system where any of those assumptions are true, though you may need to scale up a bit before you start seeing enough of those failures to care. So the suggestion of using something like monit or supervisord without addressing the amount of functionality you lose if you do makes me question if you understand the purpose of the pieces you are tearing out and/or whether you have put any thought into how users can regain that functionality without ending up making the same tradeoffs systemd does after all. I'm all for getting something more modular than systemd, but ultimately I think few people will be well served by giving up on the substantial improvements systemd is bringing. |
PID files and SysV initscripts are broken. We're well aware and this has been common knowledge for a long time. What I meant was that you can still get more potential from a dedicated program that tries to focus and solve cases in one specific areas. Making a distinction between the init part and the manager/supervisor part is one of our longer term goals with uselessd, beginning with version 5. It's a trade-off.
We understand what we're doing, and we do not deny the presence of warts. When we announce that we're stable and ready for system integration, then we can really talk. As it stands now, this is all preliminary pondering.