Writing to Custom Log Files from Bash Scripts: An In-Depth Analysis from logger to Syslog Configuration

Introduction

In Linux system administration, logging is a critical aspect for monitoring and debugging applications. Many developers use the logger command to write messages to system logs, but by default, these messages are sent to the /var/log/messages file. When redirecting logs to a custom file is required, simple redirection often fails due to the tight integration of logger with the syslog service. This article analyzes this mechanism in depth and presents multiple methods for achieving custom logging.

How the logger Command Works

The logger command is part of the syslog system logging utility. It sends messages to the syslog daemon (e.g., rsyslog or syslog-ng) via Unix domain sockets, rather than writing directly to files. Thus, when executing logger "have more fun" > /var/log/mycustomlog, the redirection only applies to the command's standard output, and logger does not produce standard output by default, leaving the custom file empty. Messages are still processed by syslog and logged to the default location.

Implementing Custom Logs via Syslog Configuration

To direct messages to a custom file using logger, the syslog configuration must be modified. Syslog uses facilities and priorities to categorize messages. For instance, a custom facility like local7 can be assigned and configured to output to a specific file. Add the following line to /etc/rsyslog.conf or a similar configuration file:

local7.*   -/var/log/mycustomlog

This line instructs syslog to write all messages from the local7 facility (regardless of priority) to the /var/log/mycustomlog file. The hyphen - disables synchronous writes for better performance. After modification, restart the syslog service, e.g., using systemctl restart rsyslog. Then, messages can be logged by specifying the facility and priority:

logger -p local7.info "information message"
logger -p local7.err "error message"

This will cause messages to appear in /var/log/mycustomlog with appropriate log levels, facilitating later analysis. This method maintains consistency with the system logging framework, supporting log rotation and centralized management.

Alternative Methods Using logger

Without modifying syslog configuration, the logger command offers the -s option to output messages to standard error (STDERR) as well, which can be captured via redirection. For example:

logger -s "foo bar" 2>> /var/log/mycustomlog

Here, 2>> appends standard error to the file. However, note that messages are still logged via syslog to the default location, potentially causing redundancy. Thus, this approach is suitable for temporary debugging or simple scenarios, not as a best practice for production environments.

Simple Alternative: Using the echo Command

For simple scripts that do not require integration with syslog, using the echo command directly is a more straightforward option. For example, to overwrite a custom log file:

echo "This logs to where I want, but using echo" > /var/log/mycustomlog

Or to append log content:

echo "I will just append to my custom log file" >> /var/log/customlog

This method avoids the complexity of syslog but lacks advanced features like log levels and automatic timestamps. Developers must handle these elements manually, e.g., by combining with the date command: echo "$(date): error occurred" >> /var/log/mycustomlog. Additionally, file location should be considered: /var/log/ is typically reserved for system daemons, while user logs might be better placed in ~/logs/ or application-specific directories.

Conclusion and Best Practices

When implementing custom logging in Bash scripts, the choice depends on the complexity of requirements. For applications needing integration with system logs, support for multiple levels, and long-term maintenance, using the logger command via syslog configuration is recommended. This ensures consistency, manageability, and scalability of logs. For simple scripts or rapid prototyping, the echo command offers a lightweight solution, but attention must be paid to manually managing log formats and storage locations. Regardless of the method, following best practices in logging—such as regular rotation, monitoring, and security considerations—enhances system reliability and maintainability.