Use this documentation with care! It describes
the outdated version 7, which was actively
developed around 2014 and is considered dead by the
This documentation reflects the latest update of the v7-stable branch. It describes the 7.6.8 version, which was never released. As such, it contains some content that does not apply to any released version.
To obtain the doc that properly matches your installed v7 version, obtain the doc set from your distro. Each version of rsyslog contained the version that exactly matches it.
As general advise, it is strongly suggested to upgrade to the current version supported by the rsyslog project. The current version can always be found on the right-hand side info box on the rsyslog web site.
Note that there is only limited rsyslog community support available for the outdated v7 version (officially we do not support it at all, but we usually are able to answer simple questions). If you need to stick with v7, it probably is best to ask your distribution for support.
omprog: Program integration Output module¶
Module Name: omprog
**Available since: ** 4.3.0
Author:Rainer Gerhards <firstname.lastname@example.org>
This module permits to integrate arbitrary external programs into rsyslog’s logging. It is similar to the “execute program (^)” action, but offers better security and much higher performance. While “execute program (^)” can be a useful tool for executing programs if rare events occur, omprog can be used to provide massive amounts of log data to a program.
Executes the configured program and feeds log messages to that binary via stdin. The binary is free to do whatever it wants with the supplied data. If the program terminates, it is re-started. If rsyslog terminates, the program’s stdin will see EOF. The program must than terminate. The message format passed to the program can, as usual, be modified by defining rsyslog templates.
Note that each time an omprog action is defined, the corresponding programm is invoked. A single instance is not being re-used. There are arguments pro and con re-using existing binaries. For the time being, it simply is not done. In the future, we may add an option for such pooling, provided that some demand for that is voiced. You can also mimic the same effect by defining multiple rulesets and including them (at the price of some slight performance loss).
- sets a new default template for file actions.
- binary Mostly equivalent to the “binary” action parameter, but must contain the binary name only. In legacy config, it is not possible to specify command line parameters.
The following command writes all syslog messages into a file.
Module (load=”omprog”) *.* action(type=”omprog” binary=”/pathto/omprog.py –parm1="value 1" –parm2=value2” template=”RSYSLOG_TraditionalFileFormat”)
Legacy Configuration Directives:
- $ActionOMProgBinary <binary> The binary program to be executed.
Currently none known.