When starting out with a script it may be appropriate to simply redirect printf output to a file, but to scale we can use logger:

  • Parallel processes can’t write safely to the same file, because file writes are buffered. The buffer size varies, but on my system a simple character repetition ended up producing interleaved sequences of 4096 As and Bs:

    logger will interact with the configured system log directly, which hopefully is set up to handle this gracefully. In systemd, for example, each log message is associated with the PID of the logger command, and two concurrent logger messages can be easily distinguished.

  • Once we end up with many scripts it becomes arduous to keep all the log formats in sync to enable easy debugging. logger passes the message with metadata to the logging system, so there is no need to propagate the log format in each script.

  • logger supports The Syslog Protocol, so interacting with compliant servers for centralized logging is available out of the box.

logger MESSAGE logs the given message to the currently active log mechanism, which may be anything at all. Many systems used to be configured by default to log to the file /var/log/syslog. Nowadays it’s more common to log to a journal on desktop systems and to a log aggregation service on servers. If you are on a system with systemd, for example, you can run journalctl --follow to show log entries as they show up in the systemd journal. Open another terminal and see what shows up in the journal window when experimenting with various commands and options. For example, to send a user–level warning to the journal and also to standard error:


This page is a preview of The newline Guide to Bash Scripting

No discussions yet