Bug 755803

Summary: all early boot messages lost
Product: [Fedora] Fedora Reporter: Rudd-O DragonFear <rudd-o>
Component: rsyslogAssignee: Tomas Heinrich <theinric>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 16CC: johannbg, lpoetter, metherid, mschmidt, notting, plautrba, pvrabec, systemd-maint, theinric
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-12 16:18:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
precise log output written by rsyslog when told to write ALL facilities and priorities to a single file none

Description Rudd-O DragonFear 2011-11-22 05:12:34 UTC
Description of problem:

logs in /var/log only show messages from a very late stage in the boot process

all  early boot messages are in the kernel ringbuffer (dmesg) but are never written to any file.  worse off, when started with systemd.log_level=debug, they are so many that the ringbuffer cannot fit them, making it impossible to debug the first log messages.

boot.log is ALWAYS empty too.

this is contrary to old system behavior and to systemd's alleged feature of saving all boot logs to a file.

Comment 1 Rudd-O DragonFear 2011-11-22 05:13:38 UTC
Created attachment 534920 [details]
precise log output written by rsyslog when told to write ALL facilities and priorities to a single file

Comment 2 Michal Schmidt 2011-11-22 12:24:47 UTC
(In reply to comment #0)
> all  early boot messages are in the kernel ringbuffer (dmesg) but are never
> written to any file.

By default, rsyslog only stores the kernel messages from the ringbuffer. You can change that in /etc/rsyslog.conf using:
$KLogPermitNonKernelFacility on

Reassigning to rsyslog to consider the possibility of changing the default.

>  worse off, when started with systemd.log_level=debug,
> they are so many that the ringbuffer cannot fit them, making it impossible to
> debug the first log messages.

That's why I always suggest log_buf_len=1M together with systemd.log_level=debug.

Comment 3 Tomas Heinrich 2012-04-12 15:24:05 UTC
(In reply to comment #0)
> Description of problem:
> 
> logs in /var/log only show messages from a very late stage in the boot process

Which logs?
Testing on f16 and f17 shows all the early messages from the ringbuffer are stored in /var/log/messages.
Some of the messages have 'debug' severity and are not included.
On f17, this roughly matches the dmesg output regardless of '$KLogPermitNonKernelFacility'.
On f16, this is similar except there appear to be some debug messages in the dmesg output from systemd. These are only logged with '$KLogPermitNonKernelFacilit on'.

> all  early boot messages are in the kernel ringbuffer (dmesg) but are never
> written to any file.  worse off, when started with systemd.log_level=debug,
> they are so many that the ringbuffer cannot fit them, making it impossible to
> debug the first log messages.
> 
> boot.log is ALWAYS empty too.

I haven't observed this.

> this is contrary to old system behavior and to systemd's alleged feature of
> saving all boot logs to a file.

Michal, though probably harmless, I'm not convinced to include this directive in the default configuration.

Comment 4 Michal Schmidt 2012-04-12 16:18:53 UTC
(In reply to comment #3)
> (In reply to comment #0)
> > boot.log is ALWAYS empty too.

boot.log gets written by plymouth.

> Michal, though probably harmless, I'm not convinced to include this directive
> in the default configuration.

Right. Don't.
Since in F17 systemd does not use the kernel buffer by default anymore (it uses the journal instead), the directive is not necessary.

In F16 the users can set $KLogPermitNonKernelFacility if needed. And if they increase the systemd log level, they can increase the kernel buffer length too.