Linux online course

Create Log Entries with logger in Linux

Learn how to use Linux logger to submit tagged messages, script events, file contents, priorities, and PIDs to syslog-compatible logging services.

The logger command lets you submit a message to the Linux system logging infrastructure from a terminal or shell script. It is useful when an administrator or script needs to record an operational event deliberately rather than relying only on logs produced automatically by an application.

Typical events include the start and completion of a backup, a failed maintenance action, a cleanup result, a warning about skipped files, or an audit-relevant administrative change. An application may generate its own structured logs; a script using logger submits a message through the host's logging interface.

What logger does

logger is a command-line utility that sends messages using the syslog message model. On many Linux systems, the message is received by systemd-journald, rsyslog, or syslog-ng. The active service and its configuration determine where the record ultimately appears.

syslog is a standard logging model that associates a message with metadata such as a timestamp, host, tag, facility, and severity. A tag identifies the program or script. A facility classifies the source category, while a severity describes how important the event is.

Basic syntax

logger "message text"

For example:

logger "Nightly maintenance task started"

The stored record may include the timestamp, hostname, facility, priority, and a default program identifier such as logger. The exact display depends on the journal or syslog viewer.

Where logger messages are stored

There is no universal log file path on Linux. A systemd-based host may retain messages in the journal. A file-based syslog configuration may route them to /var/log/messages, /var/log/syslog, a dedicated file, or another destination. Messages can also be forwarded to a remote logging server.

systemd journal — Likely destination: the journal — Inspection: journalctl — The journal may be the only local destination.

rsyslog on Red Hat-family systems — Likely destination: often /var/log/messages — Inspection: tail -n 50 /var/log/messages and the rsyslog configuration.

rsyslog on Debian-family systems — Likely destination: often /var/log/syslog — Inspection: tail -n 50 /var/log/syslog and the rsyslog configuration.

Custom rsyslog routing — Likely destination: any configured file, including a dedicated application log — Inspection: search /etc/rsyslog.conf and /etc/rsyslog.d/.

To search recent journal entries by tag:

journalctl -t backup-job -n 50

To follow new entries interactively:

journalctl -f -t example-script

When rsyslog is responsible for file routing, inspect its rules:

grep -R "local0\|/var/log" /etc/rsyslog.conf /etc/rsyslog.d/ 2>/dev/null

Logging messages with useful metadata

Quoting messages

Quote a message containing spaces so the shell passes it as one argument:

logger "Backup completed successfully"

Quoting also protects characters that the shell might interpret. Use single quotes when the message should contain literal dollar signs or command substitutions:

logger 'Received literal $HOME value'

Use double quotes when you intentionally want shell variables expanded:

count=42
logger "Backup completed: $count files copied"

Adding a process ID with -i

The -i option includes the process identifier, or PID, associated with the logger invocation:

logger -i -t maintenance "Temporary files cleanup completed"

A PID is a number assigned to a running process. It can help correlate several messages with a process execution. Note that -i records the PID associated with the logger process, not necessarily the PID of a separate command that your script just ran.

Assigning a custom tag with -t

Use -t to give messages a stable application, script, or service identity:

logger -t backup-job "Backup started"

A consistent tag makes searches and filters easier than relying on a generic command name. Choose a short, stable name such as backup-job, cleanup-script, or inventory-sync.

Showing the message on the terminal with -s

The -s option also writes the submitted message to standard error, commonly called stderr. This is useful during interactive testing or script debugging:

logger -s -t deploy "Deployment validation failed"

Terminal output and system logging are separate destinations. -s does not replace the system log submission; it adds a local stderr copy.

Submitting a file with -f

The -f option reads a file and submits its contents as log input:

logger -t report-import -f /tmp/import-summary.txt

This can be useful for a short status report or diagnostic summary. Review the input before logging it. Large files can create excessive log volume, multiline content may be displayed or routed differently than expected, and untrusted or sensitive content may expose information. Never send passwords, API keys, access tokens, personal data, or other secrets to system logs.

Common logger options

-i — Include the logger invocation's PID — logger -i "Cleanup finished"

-f FILE — Read and submit file contents — logger -f /tmp/status.txt

-t TAG — Set the message tag — logger -t backup-job "Backup started"

-s — Also write the message to stderr — logger -s "Testing logging"

-p PRIORITY — Set facility and severity — logger -p local0.warning "Skipped files"

Installed versions can have additional options or slightly different behavior. Read the local manual:

man logger

Facilities and priorities

A syslog facility identifies the source category of a message. Common choices for locally written scripts are user and local0 through local7. Local facilities are useful when administrators want dedicated routing rules without mixing script events with unrelated system messages.

A priority combines a facility and a severity in the form facility.severity:

logger -p local0.warning -t backup-job "Backup completed with skipped files"

Common severities, from less urgent to more urgent among those commonly used by scripts, include debug, info, notice, warning, err, and crit or critical, depending on the command's accepted spelling.

debug — Detailed information useful while diagnosing behavior — A temporary diagnostic value or decision path.

info — Normal successful operation — A backup completed.

notice — Significant normal event — A configuration reload or planned maintenance action.

warning — An unusual condition that did not necessarily stop the operation — Some input files were skipped.

err — An operation failed or produced an error — A backup command returned a nonzero status.

Use severity consistently. Do not mark every ordinary event as an error, and do not hide failures as informational messages.

Using logger in shell scripts

A useful script logging pattern has a stable tag, a start message, a success or warning result, and a failure message that includes the exit status. Include concise context such as counts, elapsed time, destination names, and result values.

#!/usr/bin/env bash

TAG="backup-job"
DESTINATION="/srv/archive"
START_TIME=$(date +%s)

logger -t "$TAG" "Backup started: destination=$DESTINATION"

if backup_command --destination "$DESTINATION"; then
    status=0
    count=42
    elapsed=$(( $(date +%s) - START_TIME ))
    logger -p local0.info -t "$TAG" \
        "Backup completed: files=$count elapsed_seconds=$elapsed destination=$DESTINATION"
else
    status=$?
    logger -p local0.err -t "$TAG" \
        "Backup failed: exit_status=$status destination=$DESTINATION"
fi

exit "$status"

Replace backup_command with the actual backup program. Capture $? immediately after a failed command if you need its exit status; running another command first can change it.

You can also log warnings and completion information during cleanup:

logger -p local0.notice -t cleanup-script "Cleanup started"

if rm -f -- /tmp/example-cache; then
    logger -p local0.info -t cleanup-script "Cleanup completed: cache_removed=true"
else
    status=$?
    logger -p local0.warning -t cleanup-script "Cleanup incomplete: exit_status=$status"
fi

Routing messages to a dedicated rsyslog file

If rsyslog is active, an administrator can route a facility to a dedicated file. For example:

local0.*    /var/log/example-script.log

Place a distribution-appropriate rule in an rsyslog configuration file, validate it, and reload or restart rsyslog according to local administrative procedures. Ensure that the dedicated file has a log rotation policy.

This rule does not make /var/log/example-script.log universal. It only applies where that rule is installed and the rsyslog service is active.

Verifying and troubleshooting delivery

Test and search by tag

logger -t example-script "Manual test message"
journalctl -t example-script -n 20

If the journal is available, this is usually the quickest way to verify a tagged message. You may need appropriate privileges to see all records on a system.

Check traditional log files

tail -n 50 /var/log/messages
tail -n 50 /var/log/syslog

Only inspect a file if it exists and is configured as a destination. If the command succeeds but the message is absent from /var/log/messages, the system may use /var/log/syslog, store messages only in the journal, route the selected facility elsewhere, or have no file-based syslog daemon running.

Common problems

  • Incorrect location assumption: Search the journal and check both the distribution's usual file destination and custom routing rules.
  • Filtering rules: rsyslog or another service may discard, redirect, or forward a facility or severity.
  • Permissions: Reading protected log files may require elevated privileges. Do not solve a read-permission problem by weakening log-file permissions.
  • Unavailable socket or service: A minimal host or container may not provide journald, a syslog socket, or a running syslog service.
  • Container logging: Containers often forward stdout and stderr through the platform rather than running a complete host logging stack. Check the container runtime's logging configuration.
  • Unexpected tag display: A viewer or forwarder may format identifier fields differently. Submit a known test with -t and compare journal output with the configured destination.
  • Hard-to-search script messages: Adopt one tag, include an event name and useful context, and reserve warning or error priorities for exceptional outcomes.

Log rotation, retention, and volume

logger submits messages; it does not manage their lifetime. Traditional files are commonly routed by rsyslog and managed by logrotate, which can archive, compress, replace, or remove old files. Journal retention is managed by journald settings and related administrative policies.

A loop or frequently called script can produce large volumes quickly. Avoid logging every iteration, full command output, or large files. Log summaries, failures, and meaningful state changes instead. Review both file rotation and journal retention when storage grows unexpectedly.

Safe logging practices

  • Never log passwords, API keys, tokens, private keys, or authentication headers.
  • Minimize personal data and other sensitive values.
  • Use concise, searchable event messages.
  • Include useful context such as an operation name, result, count, destination, or exit status.
  • Choose a stable tag for each script or service.
  • Use appropriate severity levels rather than marking every message as critical.
  • Control message frequency and review retention capacity.
  • Treat untrusted input carefully, especially when using -f or interpolating external data into messages.

Related Linux topics

For broader command-line context, see Linux, Bourne Again Shell Bash, and Show The Full Path Of Shell Commands.