On 06/08/2015 16:00, Rainer Weikusat wrote:
That's all nice and dandy but it all boils down to 'the code executed by the init script was deficient in some way'.
Yes, just like root exploits boil down to "the code executed by the suid program was deficient in some way". My point is that you shouldn't need to have 40 lines of boilerplate to sanitize your init script before you run it; if it's so fragile, then it's badly designed.
But that's something different. Using inetd as simple, well-known example, if I just changed /etc/inetd.conf, I want to daemon to reread it and reconfigure itself accordingly to avoid interrupting unrelated services but in case its on rampage in an endless loop, I want to get rid of the current process and start a new instance. 'SIGHUP' is just a random convention dating back to the times when signals where the only kind of IPC supported by UNIX(*) and the signal was basically hijacked because a 'daemon process' shouldn't ever receive it for some other reason. It's not universally supported and not all daemons are so simple that "reread the config file" is the only means of controlling them at run time. Eg, someone might want to ask bind to reload a specific zone.
All agreed. Service-specific configuration can only be achieved by service-specific tools.
Service management is a more complex task than [nohup] /usr/sbin/ochsenfrosch >>log 2>&1 &
My point exactly.
[systemd] Is it? Or is it an extremely incomplete, ad hoc designed programming language with a service manager and a truckload of other potentially useful stuff attached to it in order to encourage people to swallow the language?
I have never said, am not saying, and probably never will say that systemd is any good. It's not, and Lennart and Kay should go back to engineering school, and the people who hired them should go back to HR school. Its Embrace and Extend strategy is as pernicious as Microsoft's in the late 90s / early 2000s. It's technically inept and politically evil. Nevertheless, those guys have understood a few things, and have done a few things better than sysvinit or anything else really. You have to analyze it, cut out the bad parts and keep the good parts. The concept of service management is one of the good parts. They implemented it the systemd way, but they did implement it. Know your enemy. It's easy and tempting to rant for days on systemd's weaknesses; but it's also vital to acknowledge its strengths.
'Winning' against systemd will require getting support of a commerically more potent company than RedHat and SuSE combined and one willing to sink a sizable amount of money into the task.
No, I don't think so. You don't fight Goliath with Goliath. You don't fight Microsoft's proprietary-ness by investing into Apple. The last thing we need against systemd is another systemd, as you say yourself in the rest of your paragraph, which I fully agree with.
But 'booting the machine' is a much simpler task and it can be solved within the existing framework by incrementally adding the missing bits.
Depending on what you mean by "adding the missing bits", I may or may not agree. I'm not suggesting doing things the systemd way, but I do believe that a quantum leap is needed. Which, of course, does not preclude maintaining compatibility for some time to ease the transition.
Starting from the presumption that this will turn out to be necessary is a guess.
You either want to do things right or you don't. If you do, then it's not a guess: starting and maintaining services reliably requires more than the existing framework. There are countless web pages and heartbreaking mails on support mailing-lists to prove it. -- Laurent _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
