Since a lot of other people have been writing about systemd recently, I decided I’d post my own thoughts about it. Note that I jotted these notes down in late 2012, before systemd got forcibly rammed into the plans for pretty much every Linux distribution, and based on reading all Lennart’s postings about it. It’s possible that some of these issues have been addressed.
With systemd, every daemon has to hand over socket handling to systemd. That means portable daemons will have two different code paths, depending on whether they’re running on Linux or not. That’s a testing and reliability headache for developers.
Because systemd controls the sockets, it will end up being a dependency of every daemon, unless distributions ship both systemd and non-systemd packages for all their daemons. No doubt that’s good for forcing systemd adoption, but it’s going to be a pain for everyone else.
Got a daemon you want to run that hasn’t been systemd-ized? Good luck with that.
Seriously, it’s 2012 and you’re trying to introduce a new configuration file syntax modeled on Windows .INI files?
Systemd has a deliberately undocumented binary log file format, in an attempt to replace syslog. And no, you can’t turn off systemd’s syslog replacement and use a standard syslog.
With systemd written in C and controlling all the TCP/IP ports, it will become a primary attack vector for crackers and malware. Because it’s the init daemon, every time a systemd security update is pushed, you’ll need to reboot. But don’t worry, I’m sure the author of PulseAudio can write the kind of bug-free code necessary for good security, right?
Regarding item 5, the document arguing in favor of systemd having its own logging system gives a number of bogus reasons, so let’s go through them:
The message data is generally not authenticated
It can be if you configure syslog that way.
The data logged is very free-form. Automated log-analyzers need to parse human language strings to a) identify message types, and b) parse parameters from them.
The timestamps generally do not carry timezone information, even though some newer specifications define support for it.
I wrote about that in 2005 and a fix has been available since 2010. Here’s a log line from my server:
<22>1 2014-05-18T14:22:56.950703-05:00 castor postfix 3139 - - D4F38C1317: removed
Syslog is only one of many log systems on local machines. Separate logs are kept for utmp/wtmp, lastlog, audit, kernel logs, firmware logs, and a multitude of application-specific log formats.
Adding systemd is not going to magically stop bad software from writing its own logs in its own format, any more than the existence of syslog did. And the fact that syslog writes to multiple separate log files rather than one huge database is a feature, not a bug.
Reading log files is simple but very inefficient. Many key log operations have a complexity of O(n). Indexing is generally not available.
If only you could syslog to a database… Oh, wait, you can.
The syslog network protocol is very simple, but also very limited. Since it generally supports only a push transfer model, and does not employ store-and-forward, problems such as Thundering Herd or packet loss severely hamper its use.
Whereas systemd sends network log events over HTTP, a protocol known for its reliability, efficiency and store-and-forward support?
Log files are easily manipulable by attackers, providing easy ways to hide attack information from the administrator.
Also fixable with properly configured standard syslog.
Unless manually scripted by the administrator a user either gets full access to the log files, or no access at all.
…which is why syslog writes to multiple log files, so that access can be handled on a granular basis.
The meta data stored for log entries is limited, and lacking key bits of information, such as service name, audit session or monotonic timestamps.
Repetition, see above.
Automatic rotation of log files is available, but less than ideal in most implementations: instead of watching disk usage continuously to enforce disk usage limits rotation is only attempted in fixed time intervals, thus leaving the door open to many DoS attacks.
It’s not hard to imagine how this could be fixed by integrating rotation into syslog. In fact, there are already implementations via logging to channels.
Compression in the log structure on disk is generally available but usually only as effect of rotation and has a negative effect on the already bad complexity behaviour of many key log operations.
You can log to zip files if you care mostly about disk space, or log to a database if you care mostly about speed.
Classic Syslog traditionally is not useful to handle early boot or late shutdown logging, even though recent improvements (for example in systemd) made this work.
That’s why we have the kernel ring buffer and klogd, and then transfer those initial log records to syslog later on.
Binary data cannot be logged, which in some cases is essential (Examples: ATA SMART blobs or SCSI sense data, firmware dumps)
I see that as a feature. You log the binary blob as-is in a directory, then log its name and the other metadata in the syslog.
Basically, I don’t see any functionality in systemd’s journal that necessitates replacing syslog.