Linux Kernel Logs – Understanding Odd Lines in /var/log/kern.log

kernellinuxlinux-kernellogs

I am running Ubuntu 19.04, after installing virtualbox and rebooting, i noticed these non-descriptive lines in the /var/log/kern.log

Sep 30 16:36:34 a kernel: [  236.760271] test1
Sep 30 16:36:34 a kernel: [  236.760273] test2
Sep 30 16:41:07 a kernel: [  509.036723] test1
Sep 30 16:41:07 a kernel: [  509.036726] test2
Sep 30 16:41:25 a kernel: [  527.214838] test1
Sep 30 16:41:25 a kernel: [  527.214840] test2

What could they be?

Output of

sudo grep -wri kern /etc/*syslog*

/etc/rsyslog.d/20-ufw.conf:# normally containing kern.* messages (eg, /var/log/kern.log)
/etc/rsyslog.d/50-default.conf:kern.*                           -/var/log/kern.log

Thanks

Best Answer

_{This has been taken from https://wiki.chotaire.net/vbox-test-warning-messages. Kudos to them. If it helps you, please consider visiting them and letting them know it was helpful.}

The source code for Virtual Box 6.0.6 shows kernel print statements that have been accidentally left in the production release. If you're using rsyslog you can filter them out by adding two lines to /etc/rsyslog.conf - or create your own /etc/rsyslog.d/vbox.conf for easier administration (remember to comment there what you've done):

:msg, contains, "test1" stop
:msg, contains, "test2" stop

This has been fixed by Oracle and was released in VirtualBox Version 6.0.8.

Related Solutions

Rsyslog rule inconsistently applied

From the output you've given it looks like the python script is not sending all the pieces of the syslog message that rsyslog is expecting. It appears as if the "{FILTER}" part is where the host and app name should be. You can pretty easily prove this by running rsyslogd with the -d flag then sending the message from python and then from logger. You'll see the raw message as it comes from the socket that way and I bet you'll see that logger is sending more fields in front of the "{FILTER}" part.

Why the second log files on /var/log are not compressed

I agree with you, that should only provide an easier access to recent files. Anyway, the actual behaviour is decided via logrotate delaycompress directive, which says:

do not compress the file as you rotate, but compress it next time

The historical reason can be found in the logrotate manual:

Postpone  compression of the previous log file to the next rotation 
cycle.  This has only effect when used in combination  with compress. 
It can be used when some program can not be told to close its logfile and 
thus might continue writing to the  previous log file for some time.

Best Answer

Related Solutions

Rsyslog rule inconsistently applied

Why the second log files on /var/log are not compressed

Related Question