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