When logging out to journald, when would you use a library and when would you use systemd config options to pipe StdOut/StdErr to journald

Thermatix

5/9/24, 11:51 AM

I've found library's that allow logging out to journald which suggests that, yes you should use a library where possible and log to journald from inside your app.

But then there are tools like systemd-cat or systemd config options like this (from this) :

[Service]
StandardError=journal
StandardOutput=journal
StandardInput=null

Which suggests I can just pipe the output of stdout/stderr of the service to journald and not worry about doing something journald specific so now I'm not certain.

Can someone definitively state when it's appropriate to use one method verses another? (and any other I don't know about)

107

1 + 0

logging

systemd

journald

Score:1

Server

user1686

5/13/24, 9:14 AM

StandardOutput=journal is already the default for all services. All output generated by services just automatically goes to the journal by default even if you do not specify this option explicitly.

(This means you never need to use systemd-cat from a service; it is only useful in non-service situations, such as cronjobs or manual scripts.)

But there are two advantages to using native journald libraries (or even native syslog calls):

You can specify the message priority. It is very helpful to the admin if they can easily filter for messages by level, e.g. journalctl -p warning for "warning or higher", instead of having to scroll past hundreds of boring "info" or even "debug" level messages.

Now, this is actually possible even with stdout logging if you enable SyslogLevelPrefix= and if you make sure to prefix every stdout line with <lvl>, but nobody bothers to do it because it's optional.

In contrast, if you are using sd_journal_print() or even the traditional syslog(3) logging function, then the message priority is a required parameter of each call, so you have no choice but to specify it.

This means a service that offers native syslog or journald output will usually provide a better experience to the sysadmin than having that service configured to use stdout logging, with almost no extra cost for the developer.
You can attach various custom metadata to each message. This is specific to native journald logging (neither stdout nor traditional syslog support it). Additional metadata fields can be used either for searching and filtering the journal, or extracted and used by other tools and scripts without requiring them to parse the text message.

For example, strongSwan attaches IKE_SA_NAME= to each message, so I can easily filter messages related to my VPN with journalctl -u strongswan IKE_SA_NAME=home.

Similarly, another tool attaches a distinct MESSAGE_ID= to each different type of message, so I can find all instances of that specific message (even if its wording changes) using journalctl -o json MESSAGE_ID=asdf | jq ....

Use journalctl -o verbose and journalctl --fields to get a better idea of what's logged (e.g. take a look at systemd coredump messages – coredumpctl is just a thin wrapper around the journal).

So generally native syslog or journald output is preferred if it's available, although stdout-based logging can often be "good enough" for simple tools and scripts (especially shell scripts).

+ 1

Thermatix

5/16/24, 1:56 PM

Perfect, this is exactly what I was wanting, thank you for your well written answer!

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: When logging out to journald, when would you use a library and when would you use systemd config options to pipe StdOut/StdErr to journald

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.