Still an order of magnitude more complex than systemd.
Actually, its not. In FreeBSD, the
Then what are we discussing? Use your old style sysvinit.
Usually you can't just disable SystemD, and the tendency (IE it WILL happen), sysvinit will be removed. Try CentOS or Debian w/o SystemD and let me know how well it goes.
I don't know again what you mean. The sysvinit init scripts are still working.
They aren't, at least not fully. This requires an extra step in SystemD, to enable legacy processing of rc.d scripts.
The journald is used internally by systemd, and services can opt-in to use it.
Its not really op-in, is it? if SystemD generates diagnostic messages to journald instead of syslog or whatever you're using, you need to use it at least in some point. And when shit happens, systemD instructs you to use some crazy command to parse the binary logs, not a "hey this program is logging elsewhere". So, from a systemd user perspective, there is no other logging facility - error messages instruct you to parse journald, not to check the application log in
At least systemd captures sysout and syserr into the journal, so it's not lost
Precisely. Its not opt-in. And when you manually startup scripts, it captures the useful information the program is outputing *at that instance*.
Another huge improvement over sysvinit. How many times I had to start a daemon manually so I can see the errors from syserr.
Most daemons will log the relevant messages. And its actually trivial to enable logging of those on your startup script, if you want it (and some programs, like crontab, already have them). What we have now, are deamons silently failing and requiring an extra command to understand why.
But again, the MySQL logs are still there in
No, they aren't. In many Linux distros MySQL is configured in