2 ms·
Why, yes, I could clobber together my own server distribution with multilog and obscure init systems and whatnot, or… I could just use the distribution default,
by creshal 11y ago
Why, yes, I could clobber together my own server distribution with multilog and obscure init systems and whatnot, or… I could just use the distribution default, which massively improved over the old status quo with the introduction of systemd.
> The journal is prone to fragmentation, though it can be capped just as most sane loggers like multilog can.
So my choices are a) systemd + journald, which Just Works™ by always feeding units' stdout to it without any further configuration, b) syslog and logrotate and oh I have to patch software to use syslog in the first place and make sure logrotate rotates the files correctly if a daemon still its logfile open and… yeah, screw that, I've wasted enough of my life with that, c) something where I manually set up everything to use multilog.
> Redundant complaints, and irrelevant
From your ivory tower, maybe. Meanwhile I'm sitting in the trenches and banging my head against the wall because someone again managed to break their 300+ line init script (hi, MySQL!).
> Incorrect.
I did not mean failure cases. The average case, where every service starts up in a correct order on sysvinit/systemd, went from ~60 seconds to <20. Now, a reboot is usually faster than the failover timeout.
And unlike with Debian's "dependency-based sysvinit", systemd works. I've yet to see a failure case that wasn't caused by either hardware failure or gross operator error (e.g. referencing /var wrong in the fstab).
> Incorrect.
Well, it looks I have to throw away my perfectly working networkd setups then, if you say so.
> NetworkManager
I wasn't even talking about that. I was mainly referring to Debian's networking scripts (which have been broken and unfixed for half a decade now) and Arch's netcfg/netctl which all three never worked as advertised. If NetworkManager was actually usable on headless devices, I might prefer it over networkd, too (assuming I find a use case where either it or connman are insufficient).