Debian reconsiders init-system diversity

Posted Nov 14, 2019 15:21 UTC (Thu) by bferrell (subscriber, #624)
In reply to: Debian reconsiders init-system diversity by Deleted user 129183
Parent article: Debian reconsiders init-system diversity

It's not a matter of "as they always were done", it's a matter of "stop breaking stuff that worked before your 'fix'"

Debian reconsiders init-system diversity

Posted Nov 14, 2019 16:11 UTC (Thu) by pizza (subscriber, #46) [Link]

> It's not a matter of "as they always were done", it's a matter of "stop breaking stuff that worked before your 'fix'"

s/worked/kinda sorta worked most of the time, except when it randomly didn't/

(It's rather disingenuous to blame systemd for having the audacity to actually catch and report errors that the prior mudball blithely ignored..)

*shrug*

Debian reconsiders init-system diversity

Posted Nov 14, 2019 17:16 UTC (Thu) by smurf (subscriber, #17840) [Link] (6 responses)

Yeah, it worked. Mostly. Most of the time. With random unreliable hacks, stderr habitually redirected either to /dev/null or a nonexistent console screen / serial terminal, and without any possibility to restart a service in the same environment it started up in originally.

My personal favorite init-related breakage is the far-from-empty set of daemons that refuse to start up if they find a PID file that now points to some unrelated process. But hey, the pid is valid so refuse to run, eh? (Not to mention that absolutely nobody wites these files correctly, i.e. race condition free, in the first place.)

Surprise, systemd (a) finally pushed us towards a RAM file system for /run and (b) made that kind of nonsense obsolete anyway.

Debian reconsiders init-system diversity

Posted Nov 14, 2019 18:34 UTC (Thu) by HenrikH (subscriber, #31152) [Link]

That reminds me of the horrors of the mysqld_safe script that is used under sysvinit, it has all sorts of quirks when old pids are found.

Debian reconsiders init-system diversity

Posted Nov 22, 2019 10:55 UTC (Fri) by Wol (subscriber, #4433) [Link] (4 responses)

Or the horror that was bind, which was pointed out in the early days of systemd ...

It required the network service to be running when it shut down, else it would get stuck in an infinite loop. If your system happened to shut down networking before bind ... if it was in a remote co-lo you were SOL.

Oh and I think this took *years*, *if ever* to get fixed in the official repo.

Cheers,
Wol

Debian reconsiders init-system diversity

Posted Nov 24, 2019 20:59 UTC (Sun) by flussence (guest, #85566) [Link] (3 responses)

BIND is very... 1980s software. It's ugly, hard to use right, prone to falling over in a slight breeze, and has better replacements, yet everyone clings to it for some reason.

Debian reconsiders init-system diversity

Posted Nov 27, 2019 17:01 UTC (Wed) by anselm (subscriber, #2796) [Link]

BIND 9 actually borders on the usable. In addition, while there are loads of purported “BIND replacements” they often implement only that part of the functionality of a DNS server that their authors like or agree with. If one desires a DNS server which actually does everything that the RFCs say a DNS server should do, the number of feasible substitutes for BIND is suddenly not all that large anymore.

Which is not to say that there aren't BIND replacements that are useful in many contexts (I'm a happy user of PowerDNS and dnsmasq, for example) – it's just that the “BIND replacements” tend to come with their own sets of issues. Hence, caveat emptor.

Debian reconsiders init-system diversity

Posted Nov 28, 2019 11:13 UTC (Thu) by jezuch (subscriber, #52988) [Link] (1 responses)

The same reason people cling to sysvinit, I guess? But we haven't yet had the obligatory "you'll pry bind from my cold dead hands" flamewar yet?

Debian reconsiders init-system diversity

Posted Nov 29, 2019 4:04 UTC (Fri) by flussence (guest, #85566) [Link]

That kind of got overshadowed by the systemd thing going on at the time. It was called BIND10.