When configuring rsyslog (v8.16.0) on Ubuntu 16.04, you might encounter two common yet confusing errors:

command 'KLogPermitNonKernelFacility' is currently not permitted - did you already set it via a RainerScript command (v6+ config)? [v8.16.0 try http://www.rsyslog.com/e/2222 ]

Could not open output pipe '/dev/xconsole':: No such file or directory [v8.16.0 try http://www.rsyslog.com/e/2039 ]

The KLogPermitNonKernelFacility error typically occurs when you try to configure this directive multiple times or in incompatible ways across different configuration files. Rsyslog's newer versions (v6+) handle this through RainerScript syntax rather than legacy format.

The /dev/xconsole error stems from Ubuntu's default rsyslog configuration trying to write to a non-existent device. This was part of older console logging systems that modern Ubuntu versions don't use by default.

Here's how to resolve both issues permanently:

1. Fixing KLogPermitNonKernelFacility

Edit your rsyslog configuration (usually /etc/rsyslog.conf or files in /etc/rsyslog.d/):

# For modern rsyslog versions (v6+), use RainerScript syntax
module(load="imklog" permitnonkernelfacility="on")

# Remove any legacy format entries like:
# $KLogPermitNonKernelFacility on

2. Removing xconsole Error

Comment out or remove the xconsole line:

# Disable xconsole logging
# daemon.*;mail.*;\
#   news.=crit;news.=err;news.=notice;\
#   *.=debug;*.=info;\
#   *.=notice;*.=warn /dev/xconsole

For those using remote logging (like Loggly), here's a complete working example:

# Load required modules
module(load="imuxsock") # local system logging
module(load="imklog" permitnonkernelfacility="on") # kernel logging
module(load="omfwd") # UDP forwarding

# Template for Loggly
template(name="logglyFormat" type="string" string="<%PRI%>%protocol-version% %timestamp:::date-rfc3339% %HOSTNAME% %app-name% %procid% %msgid% [your-customer-token@41058] %msg%\n")

# Forward to Loggly
action(type="omfwd" protocol="tcp" target="logs-01.loggly.com" port="514" template="logglyFormat")

After making changes:

sudo systemctl restart rsyslog
sudo tail -f /var/log/syslog | grep -i error

You should no longer see the errors in your logs. If problems persist, check for multiple configuration files that might contain duplicate directives.

---

If you're seeing the command 'KLogPermitNonKernelFacility' is currently not permitted error in your syslog, you're not alone. This typically occurs when trying to configure rsyslog (v8.16.0+) on Ubuntu systems to process non-kernel messages through the kernel logging facility.

The error message suggests you're attempting to use KLogPermitNonKernelFacility directive after it's already been set or in an incompatible configuration context. This directive controls whether non-kernel messages are allowed through the kernel message facility.

First, examine your rsyslog configuration files. The main files to check are:

/etc/rsyslog.conf
/etc/rsyslog.d/*.conf

Look for any duplicate or conflicting KLogPermitNonKernelFacility directives. A common pattern causing this issue is:

# Wrong way - duplicate declaration
module(load="imklog")
KLogPermitNonKernelFacility on
...
# Later in the same or included file
KLogPermitNonKernelFacility on

Here's the correct way to set this parameter in modern rsyslog:

module(load="imklog" permitnonkernelfacility="on")

Or alternatively, if you need to set it separately:

module(load="imklog")
global(parser.permitsNonKernelFacility="on")

The secondary error about /dev/xconsole is unrelated but often appears alongside. To resolve it:

sudo touch /dev/xconsole
sudo chmod 666 /dev/xconsole

Or better yet, if you don't need xconsole functionality, comment out or remove the corresponding line in /etc/rsyslog.d/50-default.conf:

#daemon.*;mail.*;\
#       news.err;\
#       *.=debug;*.=info;\
#       *.=notice;*.=warn       |/dev/xconsole

After making changes, always validate your configuration and restart rsyslog:

sudo rsyslogd -N1
sudo systemctl restart rsyslog

Check your syslog to confirm the errors are resolved:

tail -f /var/log/syslog

This setting is particularly useful when:

• Forwarding kernel messages to remote servers
• Processing kernel messages with custom filters
• Integrating with services like Loggly that expect certain message formats

Remember that in rsyslog v8+, the preferred method is through the module parameters as shown above, rather than the standalone directive.