Messages in this thread | | | Date | Fri, 22 Jun 2012 16:24:12 +0100 | From | "Jan Beulich" <> | Subject | Re: printk behavioral regression |
| |
>>> On 19.06.12 at 16:34, Kay Sievers <kay@vrfy.org> wrote: > On Tue, Jun 19, 2012 at 4:04 PM, Jan Beulich <JBeulich@suse.com> wrote: >>>>> On 19.06.12 at 15:53, Kay Sievers <kay@vrfy.org> wrote: >>> On Tue, Jun 19, 2012 at 3:30 PM, Jan Beulich <JBeulich@suse.com> wrote: >>>> running 3.5-rc3 on a SLE11 SP1 system, early boot messages (apart >>>> from the very first one) end up in /var/log/messages rather than >>>> /var/log/boot.msg. I didn't dig deep enough yet to figure out what >>>> is causing this, and would hope that you (having contributed most >>>> of the changes between 3.4 and 3.5-rc3) might have an idea. >>> >>> Hmm, no idea really, and why this should change. >> >> Okay, then I'll indeed need to do some debugging. >> >>> /var/log/boot.msg is a SUSE speciality, that, as far as I know, just >>> dumps 'dmesg' after bootup, it has not much to do with the normal >>> syslog/klog logging in /var/log/messages, where all your messages should >>> always end up, and what seems to work for you. > > Sure? The /var/log/boot.msg gets overwritten with every reboot, I > don't remember losing all bootup messages in syslog on SUSE; and that > would seriously weird if it behaves like that. > >> No, boot messages (at least by default) end up _only_ in >> /var/log/boot.msg, and thus significantly help keeping the size >> of /var/log/messages down. SUSE specialty or not, there >> clearly is some user space visible change here. > > Look out for the SUSE tool blogd and how that is involved in getting > these messages from the kernel.
The new code made SYSLOG_ACTION_READ return just a single message, whereas the old implementation filled the buffer as far as data was available. I'll send a patch in a minute.
> And there is a fix pending in Greg's tree: > > http://git.kernel.org/?p=linux/kernel/git/gregkh/driver-core.git;a=commit;h=4 > a77a5a06ec66ed05199b301e7c25f42f979afdc > > which is supposed to fix a different issue, but we can never know ...
It does, yet I believe the fix I'm going to send addresses this as well, in a more natural way. So I'd suggest considering reverting that one.
Furthermore, the other fix from Yuanhan seems wrong to me altogether: It causes the message that didn't fit to not be reported anywhere (as syslog_req and syslog_idx already got bumped). The issue that was attempted to be addressed there will as well be addressed in a different way in the forthcoming patch.
Jan
| |