Bug 163461

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.

Good. Thanks! 
L.

FYI, I have the same issue.

Scott Carper

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" 
  ...

(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.

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.

Marcel - that's probably related to a SELinux mislabeling, and has nothing to do
with this issue.

(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" 
>   ...
> 
> 

(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.

*** Bug 185271 has been marked as a duplicate of this bug. ***

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.

Still empty in fc6
Tobias

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.

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?

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.

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.

AFAIK this bug made it in centos and probably rhel as well. What a pity.
Tobias

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.

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.

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" ;-)

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.

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> 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!

There's an option for binding and unbinding console drivers, which isn't
particularly of use here.

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!)

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.

dupe of bug 151238 (f8t1)

*** This bug has been marked as a duplicate of 151238 ***

I't just 2 days before F8 launch and I think still it doesn't work

Fedora 8 is out two years and a half later than I posted this still open bug. 
Amazing. Who's calling Window$ buggy...??

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.

(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.

*** Bug 443811 has been marked as a duplicate of this bug. ***

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.