Bug 163461 - Empty /var/log/boot.log file
Empty /var/log/boot.log file
Status: CLOSED DUPLICATE of bug 151238
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
:
: 185271 443811 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-17 10:48 EDT by Luis A. Florit
Modified: 2014-03-16 22:54 EDT (History)
21 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-17 12:21:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Luis A. Florit 2005-07-17 10:48:01 EDT
Description of problem:
I posted this at syslog.org, but no one answered. So, I assume it is a FC4 bug.
I upgraded to FC4, and my boot.log files are empty.
And I have the line "local7.* /var/log/boot.log"
in the syslog file.
Thanks!!
L.

My syslog.conf file:

kern.* /dev/console
*.info;mail.none;authpriv.none;cron.none /var/log/messages
authpriv.* /var/log/secure
authpriv.*;authpriv.!=notice /dev/console
mail.* /var/log/maillog
cron.* /var/log/cron
*.emerg *
uucp,news.crit /var/log/spooler
local7.* /var/log/boot.log


Version-Release number of selected component (if applicable):
Fully updated FC4, 2.6.12-1.1398_FC4

How reproducible:
Always.
  
Actual results:
Empty boot.log file.

Expected results:
Logs saved to /var/log/boot.log
Comment 1 Jason Vas Dias 2005-07-17 15:39:57 EDT
This is because initlog + minilogd (the logging system that was used before 
syslogd is started) were removed from FC4 by initscripts.
I will look into getting syslogd started earlier in the boot process.
Comment 2 Luis A. Florit 2005-07-17 21:45:53 EDT
Good. Thanks! 
L.
Comment 3 Scott Carper 2005-07-19 22:12:46 EDT
FYI, I have the same issue.

Scott Carper
Comment 4 Jason Vas Dias 2005-07-20 09:42:03 EDT
This is not a problem with syslogd . 

I have verified that syslogd runs fine with
  # chkconfig: 2345 0 99
in /etc/init.d/syslog, which should make it be started up first & shutdown last.

initscripts has commented out the logging statements in /etc/init.d/functions,
@ line 367:

# Log that something succeeded
success() {
  #if [ -z "${IN_INITLOG:-}" ]; then
  #   initlog $INITLOG_ARGS -n $0 -s "$1" -e 1
  #fi
...

# Log that something failed
failure() {
  rc=$?
  #if [ -z "${IN_INITLOG:-}" ]; then
  #   initlog $INITLOG_ARGS -n $0 -s "$1" -e 2
  #fi

initlog + minilogd have been retired.

What problems does not having the "startup/shutdown succeeded/failed" messages
in /var/log/boot.log cause you ?

You should be able to determine which services are running or stopped by 
looking at /var/lock/subsys/ .

If you really want these message back, then:

1. Change the chkconfig line in /etc/init.d/syslog to be :
     '# chkconfig: 2345 0 99
     '
   and do:
   # chkconfig --del syslog; chkconfig --add syslog

2. # cp -fp /usr/bin/logger /sbin

3. Edit /etc/init.d/functions to read, @line 367:
# Log that something succeeded
success() {
  logger -p local7.info "$1"
  ...

# Log that something failed
failure() {
  rc=$?
  logger -p local7.info "$1" 
  ...

Comment 5 Luis A. Florit 2005-07-20 09:54:07 EDT
(In reply to comment #4)
> This is not a problem with syslogd . 
> 
> I have verified that syslogd runs fine with
>   # chkconfig: 2345 0 99
> in /etc/init.d/syslog, which should make it be started up first & shutdown last.
> 
> What problems does not having the "startup/shutdown succeeded/failed" messages
> in /var/log/boot.log cause you ?
> You should be able to determine which services are running or stopped by 
> looking at /var/lock/subsys/ 

I had a [FAILED] at boot, inside all the network data at boot, and it 
scrolls so fast I wasn't able to see it. So, I didn't see what failed.
/var/log/messages didn't show anything, and, of course, I cannot find 
this info in /var/lock/subsys/. Is there any other place to look at this?

> If you really want these message back, then:
> 
> 1. Change the chkconfig line in /etc/init.d/syslog to be :
>      '# chkconfig: 2345 0 99
>      '
>    and do:
>    # chkconfig --del syslog; chkconfig --add syslog
> 
> 2. # cp -fp /usr/bin/logger /sbin
> 
> 3. Edit /etc/init.d/functions to read, @line 367:
> # Log that something succeeded
> success() {
>   logger -p local7.info "$1"
>   ...
> 
> # Log that something failed
> failure() {
>   rc=$?
>   logger -p local7.info "$1" 
>   ...

I'll do it. Thanks.

L.
Comment 6 Marcel Edward Verhagen 2005-09-02 14:40:43 EDT
I can get a error from syslog.
In the login screen I type <ctrl+f1> and log in as root.

service syslog restart

gives the following error:

syslogd: /dev/console: Permission denied

And it sais syslog has started up ok.

So I think syslog is writing to nothing.
Comment 7 Bill Nottingham 2005-09-02 14:54:39 EDT
Marcel - that's probably related to a SELinux mislabeling, and has nothing to do
with this issue.
Comment 8 Luis A. Florit 2005-11-13 14:13:39 EST
(In reply to comment #4)
Jason,

   Sorry for the delay in answering. I tested your 'recipe'. 
Althoug I have some messages in /var/log/boot.log,
I have nothing but what is already in /var/log/messages.
So, it is not really useful. I remember having a lot more 
info about the boot process in /var/log/boot.log...
Thanks,
L.

> If you really want these message back, then:
> 
> 1. Change the chkconfig line in /etc/init.d/syslog to be :
>      '# chkconfig: 2345 0 99
>      '
>    and do:
>    # chkconfig --del syslog; chkconfig --add syslog
> 
> 2. # cp -fp /usr/bin/logger /sbin
> 
> 3. Edit /etc/init.d/functions to read, @line 367:
> # Log that something succeeded
> success() {
>   logger -p local7.info "$1"
>   ...
> 
> # Log that something failed
> failure() {
>   rc=$?
>   logger -p local7.info "$1" 
>   ...
> 
> 

(In reply to comment #4)
> This is not a problem with syslogd . 
> 
> I have verified that syslogd runs fine with
>   # chkconfig: 2345 0 99
> in /etc/init.d/syslog, which should make it be started up first & shutdown last.
> 
> initscripts has commented out the logging statements in /etc/init.d/functions,
> @ line 367:
> 
> # Log that something succeeded
> success() {
>   #if [ -z "${IN_INITLOG:-}" ]; then
>   #   initlog $INITLOG_ARGS -n $0 -s "$1" -e 1
>   #fi
> ...
> 
> # Log that something failed
> failure() {
>   rc=$?
>   #if [ -z "${IN_INITLOG:-}" ]; then
>   #   initlog $INITLOG_ARGS -n $0 -s "$1" -e 2
>   #fi
> 
> initlog + minilogd have been retired.
> 
> What problems does not having the "startup/shutdown succeeded/failed" messages
> in /var/log/boot.log cause you ?
> 
> You should be able to determine which services are running or stopped by 
> looking at /var/lock/subsys/ .
> 
> If you really want these message back, then:
> 
> 1. Change the chkconfig line in /etc/init.d/syslog to be :
>      '# chkconfig: 2345 0 99
>      '
>    and do:
>    # chkconfig --del syslog; chkconfig --add syslog
> 
> 2. # cp -fp /usr/bin/logger /sbin
> 
> 3. Edit /etc/init.d/functions to read, @line 367:
> # Log that something succeeded
> success() {
>   logger -p local7.info "$1"
>   ...
> 
> # Log that something failed
> failure() {
>   rc=$?
>   logger -p local7.info "$1" 
>   ...
> 
> 

Comment 9 Luis A. Florit 2005-11-13 14:25:32 EST
(In reply to comment #8)
Sorry, I made a mistake. 
Now I observed that the lines in /var/log/messages 
that are in /var/log/boot.log are new, added by logger.
Anyway, the info about the boot process in /var/log/messages, 
without these lines, apper to contain the one in /var/log/boot.log.

L.

> Jason,
> 
>    Sorry for the delay in answering. I tested your 'recipe'. 
> Althoug I have some messages in /var/log/boot.log,
> I have nothing but what is already in /var/log/messages.
> So, it is not really useful. I remember having a lot more 
> info about the boot process in /var/log/boot.log...
> Thanks,
> L.
Comment 10 Bill Nottingham 2006-03-13 13:04:08 EST
*** Bug 185271 has been marked as a duplicate of this bug. ***
Comment 11 JM 2006-04-10 19:06:39 EDT
Are there any plans to bring the boot.log back in FC5? I ask this question
because I upgraded to FC5 and the boot.log is still empty.
Comment 12 Tobias Oed 2006-11-23 10:05:48 EST
Still empty in fc6
Tobias
Comment 13 Dave Frailey 2006-11-27 21:48:47 EST
This stinks.  We need to know *what did* happen during boot -- not what we 
think happened by spending a lot of effort comparing /var/log/subsys to what 
chkconfig says should be running, and trying to figure out what didn't start, 
etc., etc.

Comment 14 Patrick Murphree 2007-01-23 13:32:24 EST
Are there plans to reinstitute the boot.log with out the use of initlog + 
minilogd?  I understand that they are retired, but it doesn't seem to make much 
sense to retire something and not have its functionality replaced by something 
else.

Is it Redhat's position that dmesg is the replacement?
Comment 15 Wayne Pollock 2007-02-28 21:41:07 EST
The empty boot.log file is a CRITICAL problem.  There IS NO WORK-AROUND DEFINED!
It is insane to think that examining services to see which ones did or didn't
start is in any way a replacement for seeing the error messages produced by the
failed services at boot time.  An interactive boot is not always possible
either.

That fact that this severe bug has not been addressed in 3 releases boggles the
mind.  Fedora Core can't be taken seriously for a production server, unless
there is a boot log.  If this is a marketing ploy to encourage sales of RHE,
it is an evil plan.

I certainly hope FC 7 *will not ship* without some sort of boot log!  Please
change the severity of this but to "urgent", and evter it for all FC versions.
Comment 16 Casual J. Programmer 2007-06-20 00:36:25 EDT
In fact Fedora 7 did ship with the bug still unfixed. This really disqualifies
usage of F7 as serious platform, as you will have a hard time in proving what
happened at boot time if something goes wrong, no IT-Manager I know would accept
this.

Setting it up per Comment #4 helps, but still not all messages flickering over
the screen at boot time are found in /var/log/boot.log. Anyway it is probably
not good practice to deliver a crippled system and let the users find out by
themselves how to fix it.
Comment 17 Tobias Oed 2007-06-21 14:22:46 EDT
AFAIK this bug made it in centos and probably rhel as well. What a pity.
Tobias
Comment 18 DaveG 2007-06-28 09:46:00 EDT
Does anyone know why boot logging was removed in the first place? There's a 
large community out here that could help fix the original issue or track down a 
suitable replacement, if we knew what to look for.

I hate having to reboot production machines repeatedly just to sit by a console 
trying to catch error output, fingers poised over CTRL+S. Not everyone has 
access to a serial console or parallel printer (or even a spare monitor and 
keyboard!). This is becoming a serious issue. I don't mind missing the 
start/stop messages, it's the error output from rc.sysinit I'd like to see.

--DaveG.
Comment 19 Bill Nottingham 2007-06-28 10:21:04 EDT
1) didn't catch all cases
2) interfered with some scripts
3) slowed down boot by 10%+

As it's been off for (unfortunately) a while, I suspect that the old code at
this point has a) broken in other ways b) almost certainly doesn't work with
SELinux.

Comment 20 Vasiliy Kotikov 2007-07-21 08:57:31 EDT
RHEL 5 Server has this problem... as CentOS 5

http://www.linuxquestions.org/questions/showthread.php?t=562150
I haven't expected from Redhat such a "miss" ;-)

Comment 21 Jameson Williams 2007-09-13 17:24:05 EDT
This does, in fact, suck wicked bad. I still can basically not believe it has
gone on this long. If I knew how to help, I would.
Comment 22 Wayne Pollock 2007-10-02 02:05:15 EDT
It occurred to me that it would probably be a small change
to the console driver to include complete console output logging.

If this "feature" were compiled in and initially "on" (with
a boot parameter maybe, or a compiled in default settable
as a kernal build option), then it could be turned off
(perhaps via procFS interface) and captured to a boot log as
a final step in rc.local (or whatever system init system is
in use).

I made this suggestion to a kernel driver developer.  Here was
his response (10/2/2007):
"Greg KH" <greg@kroah.com> wrote:
> The kernel already supports this, Red Hat just turns
> it off in their builds.  If you don't like that, don't
> use their kernels :)

Is this true?  Either way a text capture of dev/console
would not only seem to permanently solve a boot log problem,
it would enable console session logging a bonus.  Please look
into this?  Thanks!
Comment 23 Bill Nottingham 2007-10-02 17:15:51 EDT
There's an option for binding and unbinding console drivers, which isn't
particularly of use here.
Comment 24 Wayne Pollock 2007-10-02 22:52:42 EDT
I figured "Greg" was wrong, but I think this may be a good solution.
RH can develop a kernel patch and permanently solve the boot log problem,
regardless of the init system used.  (I believe the potential change
from Sys V init was why the old logging system was dropped.)

If this "feature" were compiled in and initially "on" (with
a boot parameter or maybe a compiled in default settable
as a kernel build option), then it could be turned off
(perhaps via procFS or sysfs interface) and captured to a
boot log as a final step in rc.local.  The idea is similar
to dmesg but all output sent to the console is captured.

It doesn't seem to me (an outsider to kernel development) that this
change would hurt anything: the extra if statement in a console
driver would not be a significant performance problem, the
implementation straight-forward.  If "off" by default, no real memory
impact either.  Even if on, a boot log (or console log) shouldn't
require too much RAM, a few dozen kilobytes should be enough.  and unlike
the old (or alternative) boot log systems, this proposal requires no changes
to init scripts (or even knowledge by init script authors, it would just
work).

If my assumptions are correct please develop a patch for this for the
next version of RH/Fedora?  We've been without a boot log for too long!
(If this sounds like a good idea, feel free to take all the credit!)
Comment 25 Bill Nottingham 2007-10-03 12:20:03 EDT
As messages could be alternately sent to /dev/console or the specific backing
device, or even to a new tty (/dev/tty0, /dev/pts/0 in the case of rhgb), it's
not that simple.
Comment 26 Michael Schwendt 2007-10-07 05:33:28 EDT
dupe of bug 151238 (f8t1)
Comment 27 Will Woods 2007-10-17 12:21:30 EDT

*** This bug has been marked as a duplicate of 151238 ***
Comment 28 Adrin Jalali 2007-11-06 05:05:35 EST
I't just 2 days before F8 launch and I think still it doesn't work
Comment 29 Luis A. Florit 2007-11-20 07:18:16 EST
Fedora 8 is out two years and a half later than I posted this still open bug. 
Amazing. Who's calling Window$ buggy...??
Comment 30 Adrin Jalali 2007-11-22 10:45:24 EST
Seems no one's listening to us. Sometimes some bugs make some others
dissapointed from some other others. Hope some one from some other others
answers here.
Comment 31 Luis A. Florit 2008-03-15 11:20:55 EDT
(In reply to comment #30)
> Seems no one's listening to us. Sometimes some bugs make some others
> dissapointed from some other others. Hope some one from some other others
> answers here.

This is just because this bug is a duplicate of this:

https://bugzilla.redhat.com/show_bug.cgi?id=188544

Fedora is dying...
L.
Comment 32 Bill Nottingham 2008-04-23 11:01:03 EDT
*** Bug 443811 has been marked as a duplicate of this bug. ***
Comment 33 Ray Todd Stevens 2008-04-23 11:37:02 EDT
When I did a search for this bug I just didn't go back far enough.   It would
seem to me that a bug that first showed up in FC5 should be fixed by now,
especially since it is causing so many other bugs to show up in production code.
  I discovered this because I was trying to track down a problem which had been
occurring and I have reported a bug on.   It appears the entire reason that
several bugs I have reported exist past test code is that the logging system
here has this bug.

Note You need to log in before you can comment on or make changes to this bug.