Not a huge deal, but I have to google it every few months because I don’t use it very often.
Note also that if I just want the log stream, I have to pipe through less to get the full log messages. There’s also a flag for it, but I can’t remember my workaround is easier than digging through man pages.
Again, no big deal, just friction. Like everything in the systemd ecosystem—everything is manageable, but it’s tedious.
systemd very much does do logging. systemd-journald is a compulsory part of the system. It is one big daemon that is a huge fan-in point for all log output streams. It is also the locus of the well-publicized security holes which hit the headlines recently that allowed one to gain superuser access by subverting it.
It is not how I would do logging. I wouldn't have the fan-in, only to have to filter it all back out into individual streams again in most of my use cases. I wouldn't run log services as the superuser, or as the same user accounts as other services, or as user accounts that owned anything other than the log files that they create. (Subvert an instance of cyclog, which does not use alloca(), and all that you'll gain is write access to one service's log files and log directory. You won't get superuser access. You won't get access to the logged service process, which is running as another user. You won't get access to any other service's loggers, which are running as other users. You won't even get owner access to the log directory, and the rights to alter its permissions, as the logger only has has a non-owner ACL on the directory.)
The more I use Systemd the more I actually like it. It has some weirdness to it and there are parts that aren't really useful.
Journald is pretty stupid when you think about it. Either you're setup is really small, and logging to text files by defaults would be simpler to use. Alternatively your setup is large enough that you have a log-host/log-analytics, and logging to text files would be a sane default, as you need to convert the binary log to text anyway to do log-shipping.
It hard to argue that writing startup script hasn't improved. I would much rather write a service file than an up-start script.
I love systemd, I just hate journald. Their built-in pager sucks (text flowing off the screen by default, really?), and logging in binary was a mistake. It doesn't integrate nicely into any of the tools I would normally use. tail in particular is pain in the ass because I have to wait for journalctl to convert the entire log back to text.
Logs are text, tools that work on logs expect text, and I don't give a crap that my logs are 50% smaller or whatever. Disk space is absurdly cheap, and logs are a minority of my disk usage.
I know it can forward to syslog, but at that point I'd rather just have syslog.
systemd is fantastic, though. I've just been building a new system and having to deal with journald is a big pain in the butt.
For POSIX systems, syslog is the standard way. For systemd-based ones, journald may be preferable because of its additional features; both support sending of logs to a remote server. I'd suggest to avoid custom logging facilities (including just writing into a file) whenever possible, since maintaining many services with each using custom logging becomes quite painful.
The assumption here is that the machine you're using to do the log analysis is also a Linux machine that uses systemd (and thus has a journalctl binary). This is not necessarily true.
A lot of the annoyance that some people have with the systemd crowd is that these kind of assumptions are made all over the place. The actual software is not bad (I really do prefer dealing with systemd units than writing shell scripts for each service) but it can be hard to get past.
I'm curious whether you think this would work on logs for custom software that by necessity didn't have either its logs or writing about its logs in the training set.
I love systemd, but from a lot of experience with it over 3 years now, that doesn't disable the journal daemon, it only prevents output piping to its binary logs. You can still poll the journal daemon for events and output it elsewhere (ex, syslog).
journald is a dependency for systemd, but systemd is not a dependency of journald... in other words you can use journald on a system that does not have systemd.
What you imply is equivalent to wanting to run Gnome without libgnome.
If you want text logs, configure journald to pass things into rsyslog or whatever other logging subsystem you prefer (there are many).
No, you cannot run systemd without journald. Journald can forward messages to another syslog implementation. Its launch is even hardcoded into systemd very early in the boot process IIRC. The intent is to capture early log messages in memory inside journald before a writable /var is available.
Most systemd services log to stdout and let systemd put it in the journal, or they log to syslog and let systemd put it in the journal. Most don’t write their own log files any more. I really recommend going that route because it is nice to be able to search the journal, especially if you provide extra metadata for each log message.
It sounds like you were using the DynamicUser=, ProtectSystem=, or ProtectHome= settings which can greatly limit where a service is allowed to read from and write to and thus require you to open specific directories back up. Instead of using ReadWritePaths=, you might prefer to set LogsDirectory=.
If you don’t want a service to log to systemd, then don’t run it in systemd?
reply