VMware ESXi and vSphere Cluster Management

Create Manual Log Entries in Linux with logger

Learn how to use Linux logger to submit manual system log messages, add tags and PIDs, log files, test scripts, and inspect records with journalctl.

The logger command lets you submit a message to the local system logging service from a terminal or shell script. It is useful when you want an administrative action, scheduled task, backup, deployment, or troubleshooting step to leave a searchable record.

This lesson assumes basic terminal use, familiarity with files and paths, and a basic understanding of shell commands, standard error, and exit statuses.

Why Create Manual System Log Entries?

Many programs create log records automatically. For example, a web server may record requests and an authentication service may record login attempts. A manual log entry is different: an administrator or script explicitly submits a message to the system logging service.

Manual entries are useful for recording events that otherwise might not be visible later, including:

• Backup jobs and the number of files processed
• Scheduled tasks run by cron or a systemd timer
• Deployment and configuration changes
• Maintenance actions and planned restarts
• Results of health checks and troubleshooting tests
• Important identifiers such as a job ID, host name, or file count

In a script, logging around an operation creates a timeline: the job started, the command succeeded or failed, and useful details were recorded. The script-generated message is submitted manually, while an application-generated record is produced internally by that application.

What Is logger?

logger is a command-line interface for submitting messages to a syslog-compatible logging system. Depending on the Linux distribution and its configuration, the receiving service may be rsyslog, syslog-ng, systemd-journald, or a combination of these services.

syslog describes a widely used logging protocol and model. rsyslog is a common implementation that receives, filters, routes, and writes messages. systemd-journald is the systemd logging component that stores journal records and may forward them to a syslog service.

The general command structure is:

logger [options] message

Options can set a tag, include a process identifier, select a facility and priority, read lines from a file, or display a copy on standard error.

Create a Basic Log Message

Submit a short message to the local logging service:

logger "maintenance task started"

The command normally returns no visible output when the message is accepted for submission. That does not mean the message must appear in one particular file. The active logging configuration decides where it is stored or forwarded.

On a system using the systemd journal, search recent records with:

journalctl --since "10 minutes ago"

You can also look at common text-log files when they exist:

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

Reading these files may require elevated permissions. A message can be stored in /var/log/messages, /var/log/syslog, the journal, another configured destination, or a remote logging system.

Where Submitted Messages Are Stored

A facility is a syslog classification for the source category of a message, such as user or local0 through local7. A priority is a severity level such as debug, info, notice, warning, or err. Logging rules can route different facility and priority combinations to different files or services.

Common logger Options

Include the Logger Process ID

The -i option adds a process identifier to the record:

logger -i "manual diagnostic event"

A PID, or process identifier, is a number assigned by the operating system to a running process. A PID can help correlate a log record with other process-related evidence during diagnosis.

logger -t backup-job "script_pid=$$ backup started"

Use a Custom Tag

Without -t, the logging implementation generally uses a default program or command identifier as the tag. A custom tag gives related messages a predictable label:

logger -t backup-job "backup started"

A tag is a label attached to a log message, usually identifying the command, application, or script that produced it. Consistent tags make searching and filtering easier:

journalctl -t backup-job

Tags are commonly case-sensitive in searches, so use the same spelling and capitalization each time.

Log the Contents of a File

Use -f to read messages from a file:

logger -f /path/to/report.txt

File content may become multiple log records, commonly one record for each line. A multiline report can therefore create many entries rather than one large entry.

Preview a file before submitting it:

nl -ba /path/to/report.txt

Take care with sensitive files. Do not submit passwords, private keys, access tokens, personal data, or confidential configuration unless the logging policy explicitly permits it. Avoid sending very large files because they can create excessive records, consume storage, make searching harder, and expose information to additional log readers. For a large report, log a summary and save the report in an appropriately protected location.

Write to the Screen and the Log

The -s option sends the message to the logging service and also writes it to standard error:

logger -s -t test-log "testing system logging"

Standard error, written as stderr, is an output stream normally displayed in the terminal. This option is useful during interactive testing and while developing scripts because you can see the event immediately while still creating a system log record.

Redirect standard error when needed:

logger -s -t test-log "testing system logging" 2>logger-errors.txt

Do not confuse the displayed copy from -s with verification that the backend wrote the message to permanent storage. Verify through the journal or the configured text log as well.

Set a Facility and Priority

When supported by the local logger implementation, -p selects a facility and priority:

logger -p local0.notice -t backup-job "backup completed"

Here, local0 is the facility and notice is the priority. The receiving service may have rules that route local0 messages to a particular file, forward them, or discard them. Therefore, choosing a priority does not guarantee a specific destination.

Use logger in a Shell Script

A reliable job records a start event, important identifiers, success or failure, and useful metrics. The following backup-style example logs the start time, tests the backup command's exit status, and records a processed-file count:

#!/usr/bin/env bash

set -u
TAG="backup-job"
source_dir="/srv/data"
backup_dir="/backups/data"

logger -t "$TAG" "backup started; source=$source_dir destination=$backup_dir"

if run_backup "$source_dir" "$backup_dir"; then
    count=$(find "$source_dir" -type f -print | wc -l)
    logger -t "$TAG" "backup completed; files_processed=$count"
else
    status=$?
    logger -p local0.err -t "$TAG" "backup failed; exit_status=$status"
    exit "$status"
fi

In this example, run_backup represents the backup command or function used in the real script. The if statement checks its exit status immediately. The failure branch logs before exiting, so an unsuccessful job does not look successful in the system log.

You can also include a job identifier or the script PID:

job_id="$(date +%Y%m%d-%H%M%S)"
logger -t backup-job "job_id=$job_id script_pid=$$ backup started"

Place logger calls around the operation they describe. A completion message should occur only after the command has succeeded, and a failure message should be emitted before an early exit.

Verify Messages with journalctl

journalctl queries records maintained by systemd-journald. Search by tag and time range:

journalctl -t backup-job --since "1 hour ago"

For a quick test, use a unique tag and message:

logger -t logger-test "unique logging test"
journalctl -t logger-test --since "2 minutes ago"

If the system uses traditional text logs, inspect the files that exist:

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

Use appropriate permissions when reading protected logs. A successful logger command means the message was submitted to the local logging interface; it does not guarantee that a particular daemon, file, or remote collector retained it.

Log Rotation and Retention

Log rotation is the process of renaming, compressing, retaining, and removing older logs to control disk usage. Traditional text logs may be rotated by logrotate or managed by the syslog service. Journal records are controlled by journald retention and disk-usage settings.

A message visible today may not remain in the same file indefinitely. It may move to a rotated file, become compressed, be deleted after the retention period, or be forwarded to a remote logging system instead of being kept locally.

If logs are needed for auditing or diagnosis, check the local retention policy. Determine how long records are kept, whether rotated files are compressed, whether the journal has size limits, and whether a centralized logging service receives copies.

Troubleshooting logger

No message appears in /var/log/messages

• The distribution may use /var/log/syslog instead.
• The message may be stored only in the systemd journal.
• The syslog daemon may not be installed or running.
• The active rules may not route the selected facility and priority to that file.
• The message may be routed to another local or remote destination.

Try the following checks:

journalctl --since "10 minutes ago"
tail -n 50 /var/log/messages
tail -n 50 /var/log/syslog

If necessary, inspect the active rsyslog or syslog-ng configuration and check the status of the local logging service.

The tag is not found

The command may have been run without -t, the search spelling may differ, or the backend may expose the identifier in a different field. Repeat the test with an explicit tag:

logger -t logger-test "tag verification"
journalctl -t logger-test --since "5 minutes ago"

If the tag search fails, search recent records without a tag filter and inspect the raw text-log format or journal fields.

The script logs completion but not failure

Common causes include not testing the command's exit status, ignoring errors, or placing the failure logger call after an early exit. Use an if statement or capture the status immediately, add the failure log before exiting, and test the failure branch with a deliberately failing command.

Logging a file creates too many records

A multiline file commonly produces one record per line. Blank lines and generated diagnostic output can increase the count. Preview the file, remove unnecessary or sensitive content, or log a concise summary instead of the complete file.

Older entries are missing

Check rotated and compressed files, review logrotate settings, inspect journal retention and disk usage, and determine whether records are forwarded to a centralized logging destination.

Exam-Relevant Notes

• logger submits a message to the system logging service; it does not choose a universal log file.
• -t assigns a searchable tag.
• -i includes the PID of the logger process, not necessarily the calling script.
• -f file reads file content and commonly creates separate records for separate lines.
• -s also writes the message to standard error.
• -p facility.priority selects syslog classification and severity when supported.
• Use journalctl on systems where records are maintained by systemd-journald.
• Facilities, priorities, and logging rules determine routing and retention.

Quick Reference

logger "maintenance task started"
logger -i "manual diagnostic event"
logger -f /path/to/report.txt
logger -t backup-job "backup started"
logger -s -t test-log "testing system logging"
logger -p local0.notice -t backup-job "backup completed"
journalctl -t backup-job --since "1 hour ago"

For more practice, return to Create a Log Entry and apply these patterns to scheduled jobs, maintenance scripts, and troubleshooting workflows.