Redirecting a Program's Rsyslog Output to a Different File

Aug 30, 2014

You know what sounds good right now? Blowing a few hours trying to figure out how to redirect a program’s rsyslog output to a different log file. In case you aren’t familiar, rsyslog is the daemon that most linux systems use to handle logging a variety of system stuff such as failed login attempts, dpkg tidbits, apt-get tidbits, kernel tidbits, and pretty much everything else that’s important or standards compliant. These logs are stored in the /var/log/ directory.

You might ask, “Wow why would you blow an hour figuring out how to do something so niche?”; Well boy do I have an excuse for you, but first some background. By default, OpenVPN logs all its business using rsyslog. Now this is nice and all, but since there’s no special rules in place for handling OpenVPN logs, all of its entries are stored in /var/log/syslog, which is the default syslog output file, and OpenVPN logs a lot of stuff.

All that OpenVPN noise takes up a lot of space in the syslog file, and it shares that space with pretty much every other program that uses the rsyslog daemon. If I want to see non-OpenVPN traffic, I’d have to use grep or something on the syslog file and I’m just too lazy for that kind of jazz. OpenVPN has a configuration directive called log-append that can be used to specify a log file destination that doesn’t use rsyslog for logging, but you would lose all the benefits of using rsyslog in the first place! Rsyslog has lots of neat toys like piping log output to an external server, so using log-append is a no-go.

However, the only reason I want OpenVPN to use rsyslog is because vim has a pretty syntax highlighting for syslog files that doesn’t work for log files created using OpenVPN’s log-append directive.

It’s really a night and day difference. I figured it would be easier to screw with rsyslog configs rather than editing vim’s syntax definition for log files so here I am.

Actually setting it up

I’m going to use a Debian based system, but the process should at least rhyme for other linux platforms that use rsyslog. On Debian, the rsyslog configuration file is defined in /etc/rsyslog.conf

rsyslog.conf defines a bunch of important stuff including the line “$IncludeConfig /etc/rsyslog.d/*.conf”, which defines a directory for adding more config files. Adding config files is always better than modifying the defaults so let’s stick our config file in there.

Inside /etc/rsyslog.d/, create a ‘10-custom.conf’ file that we’re going to stick the custom config tidbits into. Notice that there’s one or more other config files in this directory with names like 50-default.conf or 40-provider.conf. These numeric prefixes designate what order these log files are concatenated in, so by naming our log file 10-custom.conf, it will come before 20-*.conf, 30-*.conf, etc.

The critical tidbit of code we’re going to add to redirect syslog output to another file is:

if $programname == 'YOURPROGRAMNAMEHERE' then {
	/var/log/THELOGNAMEYOUWANT.log
	~
}

Important note: the ‘YOURPROGRAMNAMEHERE’ variable is not the command that was used to start the program, it’s the program’s literal ‘name’. To figure out what the ‘name’ of your program is, take a look at the logs it’s been outputting to syslog.

Notice that OpenVPN is referred to as ‘ovpn-server’, that’s what we want to use for the program name.

So now if I want to clone OpenVPN logs to /var/log/openvpn.log, the config I would use in my custom config file would be

if $programname == 'ovpn-server' then {
	/var/log/openvpn.log
	~
}

If you’re not just copy-pasting all of this, you might wonder what that cute little squiggly tilde is doing after the redirect command. What this does is tells rsyslog to drop the log message immediately, preventing the log message from being caught by other filters. Since our config file is going to be pasted before the others, this will stop OpenVPN messages from being sent to /var/log/syslog.

In order to commit all these config changes, enter this business:

sudo service rsyslog restart

and you’re done!