I still do apt-get upgrades regularly on Jetson, I don’t worry about the libglx issue (I keep both this and the entire tar file of nVidia files ready), and not long ago (my upgrade was on Oct. 11, 2014) there was an upgrade to package “rsyslog:armhf” (see /var/log/apt/history.log).
The following log files no longer log:
-rw-r--r-- 1 root root 0 Feb 1 2000 aptitude
-rw-r--r-- 1 root root 0 May 13 01:27 bootstrap.log
-rw-rw---- 1 root utmp 0 Oct 1 16:52 btmp
-rw-r--r-- 1 root root 0 Oct 3 18:17 kern.log
-rw-r--r-- 1 root root 0 Oct 3 18:17 syslog
It seems like files btmp, kern.log, and syslog just now stopped logging; others are far enough in the past that they are probably unrelated. When looking back at the original configuration from sample rootfs, as well as a system.img from a while back, I see the rsyslog configuration files in /etc have changed very little (or not changed at all). This was added to rsyslog.conf, but changing or removing this has no effect:
# Enable non-kernel facility klog messages
$KLogPermitNonKernelFacility on
This is bad for kernel development, no more printk statements show up in logs. I can still use the “dmesg” command and see current printk’s, apparently because dmesg reads the kernel’s in-memory buffer…no such information makes its way to the dmesg log file (or any other file). It is no long possible to “tail -f” the kern.log file while developing, I have to manually dmesg every time now.
Is this just me, or has this happened to others with the rsyslog updated? You can check if rsyslog was updated if you get an answer from this:
sudo egrep rsyslog /var/log/apt/history.log
You can check for zero length log files via:
ls -l /var/log | egrep ' 0 '
I’m interested in knowing if this is a new rsyslog bug to turn in to the maintainers, or if this is only happening to me. How many people have a zero length “/var/log/kern.log”? If you have zero length or not zero length, have you upgraded rsyslog?