To configure Rsyslog to use the imfile module for monitoring specific log files, you must first load the module in your main configuration file and then define input rules that specify the file path, tag, and severity. This setup allows Rsyslog to treat arbitrary text files as syslog messages, enabling centralized logging and improved security monitoring without relying on standard system services.
Loading the Imfile Module
Theimfile module is not loaded by default in many minimal Rsyslog installations. You need to explicitly tell the daemon to initialize this input plugin. Open your primary configuration file, typically located at /etc/rsyslog.conf, using a text editor with root privileges. Look for the section where modules are loaded, which usually contains lines starting with module. Add the following line to load the file input module:
module(load="imfile")imfile will be ignored or cause errors during startup. If you are managing multiple configuration fragments in /etc/rsyslog.d/, you can also place this load command in a dedicated file like /etc/rsyslog.d/10-imfile.conf to keep your setup modular and easier to maintain. After making this change, it is good practice to verify the syntax before restarting the service to avoid breaking existing logging pipelines.
Defining Input Rules
Once the module is loaded, you must define specific rules that tell Rsyslog which files to watch. These rules are placed in the same configuration file or in a new drop-in file under/etc/rsyslog.d/. The basic structure of an input rule requires several parameters to function correctly. The most critical parameters are Tag, Severity, and Facility, which determine how the incoming log entries are classified when they enter the Rsyslog pipeline.
Here is a standard example of an input rule for monitoring a custom application log:
input(type="imfile"
File="/var/log/myapp/application.log"
Tag="myapp:"
Severity="info"
Facility="local0"
StateFile="/var/lib/rsyslog/imfile-state-app")File points to the absolute path of the log file you wish to monitor. The Tag parameter prefixes every message read from this file with "myapp:", which helps distinguish these logs from system-generated messages in your central logging server. The Severity and Facility fields assign a default syslog priority; if the log file itself does not contain standard syslog headers, these defaults ensure the messages are processed correctly. The StateFile parameter is crucial for tracking progress; it stores the offset of the last read byte, ensuring that Rsyslog does not re-read old data after a restart.
Handling Multiple Files
If you need to monitor multiple log files, you do not need to create separate module loads. Instead, you simply add additionalinput(...) blocks. Each block should have a unique StateFile to prevent state corruption. For instance, you might add another block for a database log with a different tag and state file location. This modularity allows you to scale your log collection strategy easily as your infrastructure grows.
Configuring Output and Filtering
After defining the inputs, you must decide where these messages go. By default, Rsyslog routes messages based on their facility and severity. Since we assigned thelocal0 facility to our example, you need a corresponding rule in the global configuration to handle it. A common pattern is to direct local facility logs to a specific file or send them to a remote syslog server.
Add a rule like the following to route these messages to a dedicated file:
local0.* /var/log/myapp/rsyslog-collected.logTesting and Troubleshooting
Before deploying this configuration to production, always test the syntax. Run the following command to check for errors:rsyslogd -N1systemctl restart rsyslog. Monitor the status with journalctl -u rsyslog to ensure the daemon starts cleanly. To verify that the imfile module is active, you can check the process list or look for the state files in /var/lib/rsyslog/. If logs are not appearing, check the permissions on the target log file to ensure the Rsyslog user has read access. For deeper debugging, enable verbose logging in the Rsyslog configuration by setting debug.level temporarily.
Frequently Asked Questions
Why are my logs duplicated when I restart Rsyslog?
Duplication usually occurs because the state file was deleted or corrupted, causing Rsyslog to re-read the entire file from the beginning. Ensure that the StateFile path in your configuration is persistent and stored in a directory like /var/lib/rsyslog/ that survives service restarts. Always back up state files before manually moving or deleting log files.
Can I use imfile to monitor binary log files?
No, the imfile module is designed to read plain text files. Binary files may contain null bytes or non-printable characters that can corrupt the syslog message format or cause parsing errors downstream. Stick to text-based logs such as those generated by applications, web servers, or custom scripts.
How do I handle log rotation with imfile?
When a log file is rotated, the old file is renamed and a new empty file is created. Rsyslog will continue reading the old file until it is empty, then stop. You should configure your log rotation tool to signal Rsyslog or update the state file appropriately. Some setups use copytruncate instead of moving files to avoid these issues entirely.
What is the difference between imfile and imklog?
imklog reads kernel messages directly from the kernel ring buffer, while imfile monitors arbitrary text files on the disk. Use imklog for standard system boot and kernel events, and imfile for application-specific logs that do not write to standard syslog sockets.
Is imfile supported on all Linux distributions?
The imfile module is part of the core Rsyslog package and is available on virtually all modern Linux distributions including Ubuntu, CentOS, Debian, and RHEL. However, the exact version of Rsyslog installed may vary, so check your documentation for module availability if you are running an older legacy system.