systemd-cat: Logging to the Journal from the Command Line

If you’re already using systemd, you’re already using the journal. And once you start treating the journal as the place your operational breadcrumbs land—service logs, one-off maintenance scripts, ad-hoc troubleshooting output—your life gets nicer.

systemd-cat is a small but powerful utility that bridges “random command output” and journald. Think of it as a journal-aware cat: it can act as a filter in a pipeline, or it can run a command and wire its stdout/stderr straight into the systemd journal.

What systemd-cat does

systemd-cat connects standard input/output to the systemd journal.

You can use it in two common modes:

• Filter mode: read from stdin and write each line to the journal.
• Command mode: run a command and capture its stdout/stderr into the journal.

In both cases, the goal is the same: give your command-line output a durable home that can be queried later with journalctl.

Why it’s useful

A few real-world wins:

• Make cron output searchable (even if you aren’t using systemd timers yet)
• Add structured “tags” to script output so you can filter it quickly
• Capture noisy maintenance runs without spamming your terminal or email
• Keep logs centralized on systems where you prefer journald over scattered log files

Basic usage

1) Pipe output into the journal (filter mode)

Anything written to stdin becomes journal entries.

2) Run a command and capture its output (command mode)

If you provide a command, systemd-cat executes it and connects both stdout and stderr to the journal.

The two options you’ll use constantly

Tag entries with an identifier: -t/--identifier=

This sets the identifier for the log messages (the same field you can filter on later).

Then you can find those entries with:

If you don’t set an identifier, journald will typically use the executable name (or cat if reading from a pipe).

Set a default priority: -p/--priority=

This sets the default log level for what’s being written.

Valid priorities mirror syslog levels (emerg, alert, crit, err, warning, notice, info, debug) or numeric values 0..7.

Handling stderr like you mean it

By default, stderr goes to the journal too. If you want stdout and stderr to be treated differently, use --stderr-priority= to set a separate default priority for stderr:

One subtle detail: if stdout and stderr have different default priorities, journald uses separate channels, so ordering between stdout and stderr will be approximately ordered rather than strictly interleaved.

Per-line priorities with --level-prefix=

Sometimes you want a script to emit mixed severity without juggling multiple processes.

When --level-prefix= is enabled (it’s the default on many systems), systemd-cat will parse syslog-style priority prefixes like <5> at the start of a line.

Example:

You can explicitly control this behavior:

• --level-prefix=yes to enable parsing
• --level-prefix=no to treat prefixes as literal text

Viewing and filtering your logs

Once the output is in the journal, the real power is retrieval:

• Follow live entries:
  
  journalctl -t rp-backup -f

  1 2	journalctl -t rp-backup -f

• Show only warnings and errors:
  
  journalctl -t rp-backup -p warning

  1 2	journalctl -t rp-backup -p warning

• View entries for a time window:
  
  journalctl -t rp-backup --since "today" --until "now"

  1 2	journalctl -t rp-backup --since "today" --until "now"

• Show entries from the last boot:
  
  journalctl -t rp-backup -b

  1 2	journalctl -t rp-backup -b

Where systemd-cat fits in the toolbox

systemd-cat vs logger

logger writes syslog messages (and on many systems those may eventually land in journald anyway).

Use systemd-cat when:

• you want to capture the whole output of a command/pipeline
• you want seamless journald integration (identifier, priorities, namespaces)

Use logger when:

• you want to emit a single log message and you’re already living in syslog-land

systemd-cat vs “just redirect to a file”

Redirecting output to a file is simple and sometimes appropriate.

But journald gives you:

• uniform retention/rotation policies
• easy time slicing and filtering
• per-unit correlation (when you’re running via systemd)
• one place to look during incidents

Practical recipes

Capture a one-off maintenance run

Make a cron job log to journald

In crontab, you can pipe stdout/stderr into systemd-cat:

This is especially handy if you’re tired of “cron emails” and would rather query logs when you need them.

Wrap a pipeline and keep it searchable

Use a journal namespace (where supported)

Newer systemd versions support journald namespaces. If your system supports it, you can target a namespace:

(If your systemd-cat doesn’t recognize --namespace, your distro’s systemd version likely predates that option.)

Gotchas and troubleshooting

• “Nothing shows up”: confirm systemd-journald is running and you’re querying the right machine/boot.
• Running inside containers: many containers don’t run journald. systemd-cat may fail or silently not do what you expect.
• You can still lose logs: journald retention/rotation may evict older entries depending on configuration and disk pressure.
• Multiline output: journald is line-oriented here—tools that print partial lines or heavy progress output may look messy.

When to reach for it

If you’re writing scripts that matter operationally—backups, renewals, deployments, rotations—systemd-cat is a low-effort way to make sure future-you (or your on-call buddy) can answer:

• Did it run?
• What did it do?
• When did it fail?
• Was it noisy, or actually broken?

And most importantly: you don’t have to invent a logging system for every script. You can just… log.