truncated dmesg on rc13 and rc15


Recommended Posts

I think dmesg/syslog is being trucated (1st lines missing) on rc13 and rc15 with new 3.9.x kernel, I'm finding strange that no one else commented it yet (or at least I could not find it), anyone else can notice it?

 

Edit: Just searched a bit and it seems it can be sorted by increasing "kernel log buffer size" (currently 16) or using log_buf_len boot option, I did tried with log_buf_len=131072 (equivalent to 17) and it seems ok now, for my test system.

 

Also I did looked at some syslogs posted on forum from other users and many are also truncated, guess new kernel may output more lines as I did never seen it on logs from previous rc's, may be eventually worth increasing it by default for final?

Link to comment

The kernel log buffer holds all the messages in ram until syslog gets started, at which point they get 'logged' there as well.  The size of this buffer has been 64K, but I notice on a 14-drive server the dmesg size is around 46K, and the kernel is bit "chattier" these days as well.  So I can see that a server with more controllers and more stuff in general could easily approach that 64K limit; in other words, it might be truncated, might not, all depends on your h/w config.  I increased to 128K for next release.

Link to comment

Well even on a test VMWare VM with just 3 hdd's I could get only near half of the dmesg! know that it was near half now comparing with complete one (with log_buf_len=131072 boot option)... latest kernel prints lots and lots and lots of acpi and available memory resources lines...

 

Also... one thing I noticed (and found it strange) is that:

 

- with 64K I was getting near half dmesg, however ls -l /var/log/dmesg did show 34xxx bytes (why half truncated if just 34K and buffer set to 64K?)

 

- with 128K (i.e. log_buf_len=131072) I do get complete dmesg and ls -l /var/log/dmesg shows 55778 bytes

 

Unless that "kernel log buffer size" counts with some extra infos, other log or something, no idea...

 

@PeterB: If you are getting complete syslog/dmesg then it should start like:

Jun 18 15:17:32 Tower syslogd 1.4.1: restart.
Jun 18 15:17:32 Tower logger: /etc/rc.d/rc.inet1:  List of interfaces: 'eth0'
Jun 18 15:17:32 Tower kernel: klogd 1.4.1, log source = /proc/kmsg started.
Jun 18 15:17:32 Tower kernel: Linux version 3.9.6p-unRAID (root@Develop) (gcc version 4.4.4 (GCC) ) #2 SMP Fri Jun 14 13:21:25 PDT 2013
...

if you can't see the line with linux kernel version then your log is missing some lines at start...

Link to comment

Just checked my syslog, I have esxi with 3 disks installed first few lines here

 

Jun 19 07:21:50 VMTower syslogd 1.4.1: restart.

Jun 19 07:21:50 VMTower kernel: klogd 1.4.1, log source = /proc/kmsg started.

Jun 19 07:21:50 VMTower kernel: acpi PNP0A03:00: Requesting ACPI _OSC control (0x1d)

Jun 19 07:21:50 VMTower kernel: acpi PNP0A03:00: ACPI _OSC control (0x15) granted

Jun 19 07:21:50 VMTower kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *9 10 11 14 15)

Jun 19 07:21:50 VMTower kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11 14 15)

Jun 19 07:21:50 VMTower kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 *10 11 14 15)

Jun 19 07:21:50 VMTower kernel: ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 14 15)

Jun 19 07:21:50 VMTower kernel: ACPI: Enabled 2 GPEs in block 00 to 0F

Link to comment

I think dmesg/syslog is being trucated (1st lines missing) on rc13 and rc15 with new 3.9.x kernel, I'm finding strange that no one else commented it yet (or at least I could not find it), anyone else can notice it?

 

Edit: Just searched a bit and it seems it can be sorted by increasing "kernel log buffer size" (currently 16) or using log_buf_len boot option, I did tried with log_buf_len=131072 (equivalent to 17) and it seems ok now, for my test system.

 

Also I did looked at some syslogs posted on forum from other users and many are also truncated, guess new kernel may output more lines as I did never seen it on logs from previous rc's, may be eventually worth increasing it by default for final?

Please verify that -rc15a solves the problem, thanks!

Link to comment