|
Systemd does use "text files or symlinks for configuration" — those being the unit files in /lib/systemd and /etc/systemd. `systemctl enable` just makes a symlink from /lib/systemd into /etc/systemd, even. What would you point to to claim that it does otherwise? > text files for logging ...just sucks, on both embedded systems and production servers. (I.e. anywhere where you aren't debugging the machine on the machine, but rather from another machine.) Either the program just writes to a plain text file forever — and so fills up your disk the first time it goes haywire (so now you have two critical runtime problems!); or it implements its own log rotation and compression (as must every other daemon — not very unixy!); or it must be specifically wired to work with syslog APIs in order to use rsyslog (which, by the way, uses binary wire protocols as well; logging at scale hasn't been text-based in a long time.) Journald, meanwhile, just sits on the other side of the pipe from any systemd service-unit's stdout + stderr; manages log rotation + compression in a centralized way (which also means you get cross-unit log compression for free); and offers CLI tooling to pipe the multiplexed log stream back into anything that wants to read from it, in whatever format those things want to read from it (i.e. tools that want JSON Lines, get JSON Lines; tools that want plaintext, get plaintext; tools that want a binary record stream, get a binary record stream.) Is this a Unixy approach? Well, it's pretty much the same one taken by the extremely venerable Unix/Linux line-printer (lp) subsystem — CLI commands, with textual config files, for interacting with a system daemon (lpd) that manages and manipulates binary state files, within daemon-owned directories. Would you complain that the contents of /var/spool/lpd aren't human-readable? |
Ehrm, no. Managing a sizeable fleet, with a central logging server for 1.5 decades, and we never had the problems you mentioned:
> and so fills up your disk the first time it goes haywire.
This is a bug of the program or configuration mistake or your monitoring is not working as intended.
Funnily, we're seeing more disk pressure from systemd journals. Go, figure.
Just remembered: syslog daemons have rate-suppression mechanisms to prevent big lines repeating too fast and preventing your disk from filling up. So even your program enters an infinite loop, a well configured syslog daemon (rsyslog, syslog-ng, whatnot), should note "X similar errors have been supressed.", where X can be anything from 2 to 1000 (or even more).
> or it implements its own log rotation and compression
Which you can disable 99% of the time and just delegate the stuff to logrotate.
> it must be specifically wired to work with syslog APIs in order to use rsyslog
rsyslog is just a syslog daemon. syslog is kernel plumbing at this level. You can terminate this pipe with anything.
> Journald, meanwhile, just sits on the other side of the pipe from any systemd service-unit's stdout + stderr; manages log rotation...
And provides nothing new when compared to syslog plumbing. A binary log, some tooling around that, and that's it. It even makes per daemon log monitoring harder by blinding syslog-aware monitoring and automation tools, hence we need to enable rsyslog on the system too. Now we have two journals. Neat.
> venerable Unix/Linux line-printer (lp) subsystem
Which only handles "line-printer" subsystem, and yes, it's more UNIXy. It doesn't get the text output, bashes into a binary data structure, and doesn't try to replace anything and everything from boot to logs to time sync to user login to tap water temperature.
It just stores its state in binary file. Which almost every UNIX daemon does. Incl, but not limited to X11 & CUPS.