4

I'm using cat /proc/kmsg to determine which process and file was involved in certain disc writes. I'm using the method given in this answer.

But when I use cat /proc/kmsg, the output doesn't always seem to update on screen in the way I expect. For example, disc writes don't always appear in the /proc/kmsg output when I expect them, and sometimes seemingly not at all. (I understand that RAM has to be written to disc before disc I/O appears in /prog/kmsg.)

Also the timestamps in the output seem to be 8 minutes behind what they should be. I want to use the timestamps.

My question is:

Is syslogd (a daemon that's running on my laptop) clashing with cat /proc/kmsg, and causing the above 2 effects? (See reference to syslog(2) in Full Details, 5.)

If so, can I safely turn off syslogd temporarily, while I use cat /proc/kmsg?

Also, what does syslogd do, and do I actually need it (I'm just using Linux on a single laptop as a single user, in multi-user mode.)?


Full Details

  1. Before doing cat /proc/kmsg, I turn off klogd to stop loads of unwanted messages going to /proc/kmsg. And I enable block_dump with echo 1 > /proc/sys/vm/block_dump.

  2. To do a test, I have cat /proc/kmsg running in one terminal, then from another terminal I perform a disc write with echo 1 > somefile. I make sure somefile doesn't already contain 1.

  3. When the arrangement is behaving, cat /proc/kmsg displays a line in response to my disc write, such as:

    <7>[ 5685.914279] bash(4413): dirtied inode 460058 (somefile) on sda6
    

But sometimes, no such line appears, even when I then type sync in the other terminal (to cause RAM to be written to disc).

  1. I understand that a) the number at the left of the /proc/kmsg line is time since boot (eg the 5685.914279), and that b) the number is seconds.microseconds. But when I do a calculation on the seconds figure, the resulting time since boot is 8 minutes behind what it should be.

  2. In man proc, I noticed the following info that I've put in capitals:

    /proc/kmsg

    This file can be used instead of the syslog(2) system call to read kernel messages. A process must have superuser privileges to read this file, and only one process should read this file. THIS FILE SHOULD NOT BE READ IF A SYSLOG PROCESS IS RUNNING WHICH USES THE syslog(2) SYSTEM CALL FACILITY TO LOG KERNEL MESSAGES. Information in this file is retrieved with the dmesg(1) program."

    So this is the reason for my MAIN QUESTION about is syslogd causing cat /proc/kmsg not to behave? I'm a relative novice, so I don't know what syslog(2) is, or what it does.

1
  • 1
    "time since boot" -> Note that does NOT include time spent in sleep or hibernation. It's not wall clock duration, it's the amount of time the system has been actually running.
    – goldilocks
    Mar 3, 2014 at 21:05

1 Answer 1

2

Use dmesg instead of cat /proc/kmsg to read messages generated by the kernel.

syslogd (or klogd) depending on the type of syslog package installed on your system, does indeed use /proc/kmsg as a data source. It then logs those messages (and loggin messages from other programs) to spool files in /var/log.

You can check your syslog config for the relevant files and locations. See /etc/syslog.conf, /etc/rsyslog.conf, or IIRC, /etc/syslog-ng.conf

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .