logd not running

[Scott James Remnant (Canonical)]

/sbin/logd is not started since Gutsy, leading to an empty /var/log/boot file

this is a setting in /etc/default/bootlogd, and the reason this has been disabled is that it caused several other processes to crash unexpectedly

[Zed Lopez (launchpad-20-zed2323)]

My /var/log/boot contains only "(Nothing has been logged yet.)" and its datestamp is from early last month, when I installed Feisty.

So I'm also experiencing logd apparently not running.

[Gaëtan de Menten (gdementen)]

For what it's worth: same problem here.

[Mackenzie Morgan (maco.m)]

I'll confirm. My last recorded /var/log/boot is 13 Feb. I guess that means that day's updates broke it. Is there a SVN or CVS or something like that for upstart somewhere to see what changed it?

[Matt Zimmerman (mdz)]

Confirmed here as well, logging hasn't been happening for quite a while

[Alex Smith (aejsmith)]

Logd doesn't get started by default or used by default because there is a bug in it, not just because it isn't started:

25-02-2007 13:43:25 <AlexExtreme> btw, what is the problem with logd?
25-02-2007 13:44:30 <Keybuk> kill it, any job with it as stdout ends up dying mysteriously and silently

[Isaac Salsberg (isalsberg)]

Logging stoped just after feisty (sucktsy) update.

The /var/log/boot file was updated the day before the upgrade.

[Peter Funk (pf-artcom-gmbh)]

I can cconfirm. that logd is not running after boot on two computers running 7.04.
The command
       sudo initctl list
reports
       logd (stop) waiting
I've stumbled over this while trying to find out, why a custom daemon I
wanted to get started during boot doesn't get started. After the
system is up, it is no problem to execute
      sudo initctl start logd
or the same command with my custom daemon and everything works
well. How should I try to debug this further? Any hints?

[Alex Smith (aejsmith)]

See what I said, it's purposely disabled for a reason. If a process is using logd for it's stdout, and logd gets stopped, that process will die with SIGPIPE

[Reinhard Tartler (siretart)]

bug is still present in current gutsy.

[Matt Zimmerman (mdz)]

My understanding from Scott is that it's been disabled intentionally, due to causing problems with processes holding file descriptors. Those issues need to be chased down before it can be enabled again.

[Bogdan Butnaru (bogdanb)]

So right now there is zero possibility to find out what happened during boot? I see messages spewing all over the console, some of them errors (that I'm trying to work out), how can I get to them?

[Mike H (mike-heden)]

Same problem here. I eventually used a digital camera to capture all the console messages during boot. In this case it enabled me to read the messages, find the underlying problem and fix it. Hardly the best solution though.....

Until there's a proper fix to this "medium" (!!) importance problem, has anyone got a better way of logging all these messages?

[littleubuntu (littleubuntu)]

man dmesg

[Mike H (mike-heden)]

Sorry, but man dmesg doesn't hack it :-)

The problem is that, as said elsewhere in the many discussions about boot-time logging, these messages do not appear in any of the system log files - /var/log/dmesg included. It's for that reason that I had to resort to video to capture the messages and be able to read them and resolve the underlying problem.

If only there were in dmesg, but it isn't that easy unfortunately.

[teedog (teedog)]

Confirming that /var/log/boot is still blank in Gutsy after setting BOOTLOGD_ENABLE to YES.

[karl (karl-sebastian-liebich)]

Confirming, too, that /var/log/boot is not filled at all after enabling bootlog - Gutsy amd64

[Scott James Remnant (Canonical) (canonical-scott)]

The logd problem is the way it works (the following is a summary, see logd(8) for more protocol detail):

Jobs specify "console logged" (once the default) in their definition, this means that Upstart will open a connection to logd for the job and bind that socket to the job's standard input/output.

The first problem was that logd needed to start before all other processes, otherwise they wouldn't be logged - so it needed to be special cased. Special casaes are bad.

The second problem was that most jobs (especially shell scripts) react quite badly to their standard output returning EBADF and just vanish -- this caused the shutdown process to suddenly stop mid-flow after it sent SIGTERM to logd.

logd should be replaced by some standard logging daemon and protocol; though that should allow Upstart to tell the logging daemon what the job details are for the process so logs can be separated.

[Scott James Remnant (Canonical) (canonical-scott)]

Not an Ubuntu bug -- it's upstream

[Savvas Radevic (medigeek)]

Here it's explained how to restart and prepare the bootlogd properly, if this is what you need:
http://ubuntuforums.org/showpost.php?p=2441664&postcount=17

[Savvas Radevic (medigeek)]

actually, it didn't work, my bad

[Pär Lidén (par-liden)]

hello, I have the same problem with the boot logging not working. All the other log files seem to work fine, but not the one logging consoloe output during boot.

The most recent data written in /var/log/boot is from 20 april this year. I guess that's when I upgraded to 7.04. This is a very annoying problem, and since it is a regression from earlier releases, I think it should have a higher priority than medium.

The reason why that forum post above does not work is because /sbin/bootlogd is not installed on Ubuntu systems (at least not mine) nowadays (probably it was in earlier releases).

The link S05bootlogd is installed into /etc/rc.[2-5].d/ and it links to /etc/init.d/bootlogd, which also exists. The problem is then that /etc/init.d/bootlogd tries to run /sbin/bootlogd, and this program is as I said not installed. Seems all very strange to me.

I remember when using Debian a few years ago, there was its own package named just 'bootlogd'. If I have understood things correctly, that old bootlog daemon ('bootlogd') has been replaced by this newer 'logd', and this logd is apparently not working correctly. Could a workaround be to somehow revive that old bootlogd package, and get it installed? Maybe it is not the proper way of doing things, but as a temporary workaround maybe? Does anyone know of any way to manually install bootlogd and get it to work in some way?

Regards
Pär

[Pär Lidén (par-liden)]

After looking around, I can see that this bug is very much connected to bug #94120.

[Scott James Remnant (Canonical) (canonical-scott)]

No, it's completely unrelated; logd and bootlogd are completely different programs with a completely different implementation.

[Pär Lidén (par-liden)]

Hello, I've found a workaround using the old bootlogd. In essence, I downloaded the sources to the sysv-init 2.86 package (from http://www.icewalkers.com/Linux/Software/58900/SysVInit.html), compiled it, and copied the bootlogd binary to /sbin (without installing the rest of the stuff).

To make it work, I had to remove the -c option to bootlog in /etc/init.d/bootlogd (BOOTLOGD_OPTS= at line 20). When booting, it says that it fails starting the bootlog daemon, but the logs appear correctly in /var/log/boot.

Probably there are some sources for an updated ubuntu version of the sysvinit package somewhere, so it would probably be better to use that sources instead. Maybe the -c option would work then also. But this works fine for me, except for that I can't view the file using the gnome system log viewer. Instead I have to open the file manually. It works, but looks a bit ugly.

You can probably move the script to somewhere early in /etc/rcS.d/ to make it log more of your booting process.

I have put the binary (compiled on ubuntu 7.10 x86-32) here for your convenience if someone of you would like to try this out.

My suggestion is that someone should put this together in a proper package so that everyone who needs it can easily install it. It would probably be an unofficial package in some way I suppose, maybe located in universe or something.

This may be an ugly workaround, but you do in fact get the bootmessages from quite early on. So in the meantime while the logging gets properly implemented, this could be an alternative IMO.

[Sergei Ivanov (svivanov)]

I think that using the old bootlogd is the right fix. It seems that bootlogd and logd can and should coexist on the same system (of course, if they write to different logfiles). They just serve different purposes.

Bootlogd is to save everything sent to /dev/console. It does not know who writes what. It can start and exit any time, and scripts do not notice any change (no SIGPIPESs, no failed IO, no nothing). This is the right tool for the problem "what did that scrolled-away messages say?".

Logd is heavier. It uses redirected output of these scripts. This allows to log them separately, but at a price: it is not transparent (a process can detect that its stdout is a socket), and it is must run forever (or at least be extremely careful with those redirected file descriptors, as they could be even passed on to daemons). It can be useful for problems like "which of these scripts issued this message?" And normally the answer should be clear even from the mixed output, so I would consider logd as a tool for special cases.

So my suggestion is to add bootlogd to the system and use logd (once it is working properly) as an additional tool when needed. Sorry if my analysis is incorrect, I'm not an expert. Maybe some developer can comment on this further.

[Gunnar Thielebein (lorem-ipsum)]

I tried the method Pär Lidén explained on gutsy_x64_86.

apt-get source sysvinit
sudo apt-get build-dep sysvinit
cd sysvninit*
debuild -us -uc
sudo cp src/bootlogd /sbin/

(attached bootlogd for gutsy x64 perhaps someone else will have try with it...)

remove "-c" option in init.d/bootlogd...

when running manual i get this:
$ sudo bootlogd:
$ bootlogd: cannot find console device 136:1 in /dev

The manpage states something with newer console format (other minor number). It also states that bootlogd tries to get console device from console param.

So I added console=/dev/console to the grub bootstring but this rendered my machine unbootable.

Question which comes up for me - What is a linux box without possibilities to debug its startup behaviour?
Hey, there are people outside which have there systems running outside a vm or headless!

[Pär Lidén (par-liden)]

I think there is a good reason that they are not using bootlogd by default. I think I read somewhere that bootlogd is quite buggy on some systems, and it is hard to make it work correctly the way it is designed. So the proper fix in the long run would be to redesign it completely, as Scott is intending to do with logd in the future. I don't remember where I read this however... Probably tekknokrat ran into one of those problems.

You may try the original 2.86 version, it may work better?

[Sergei Ivanov (svivanov)]

> I think there is a good reason that they are not using bootlogd by
> default. I think I read somewhere that bootlogd is quite buggy on some
> systems, and it is hard to make it work correctly the way it is
> designed. So the proper fix in the long run would be to redesign it
> completely, as Scott is intending to do with logd in the future. I don't
> remember where I read this however... Probably tekknokrat ran into one
> of those problems.

No, that error (cannot find console device 136:1) means that bootlogd
was run from a terminal emulator (xterm or screen or mc or ... ).
It must be run from a real console device.

Passing console=/dev/console to the kernel is an error. I think the correct
value is /dev/tty0 or /dev/tty1. And bootlogd will use something like this
anyway.

I have another problem with bootlogd. It gets confused by terminal
control codes (those that make screen output prettier). I'll try to look
at the source and see what can be done.

[Sergei Ivanov (svivanov)]

To tekknokrat. You can try out the attached source package.
This is bootlogd alone, separated from gutsy's sysvinit.
I fixed logging of terminal codes and some other minor issues.
It works for me here (Ubuntu stock kernel, no usplash, no mounting of /var).
You can build and install it with the following commands:

tar xzvf bootlogd_2.86.01.tar.gz # unpack the source
cd bootlogd-2.86.01
debuild -us -uc -b # build the package
cd ..
sudo dpkg -i bootlogd_2.86.01_*.deb # install the package

Please note that I am not an Ubuntu developer and the package is not
official in any way. So it is a good measure to audit it before installing.

In the long run, I agree that we should wait for a boot logging support
in upstart. Doing such things properly may require cooperation with
the rest of the init system.

[Pär Lidén (par-liden)]

Segei: I think you forgot to attach the actual file. ;-)

Your description of it seems very nice though, I hope they could include a package like this in the universe. I think many users would appreciate that possibility. Maybe even a package from you, if you would have the time to be maintaining it?

Cheers
Pär

[Sergei Ivanov (svivanov)]

I did attach it! Maybe launchpad does not allow this via email.
Now I am trying to do this using the web interface.

[Pär Lidén (par-liden)]

Ok, I see, then you did not forget it after all. :-)

I installed your version, it works nicely for me, and the /var/log/boot file
looks nicer than it did with my old one. Thankyou for this work. Maybe you
could submit this package to getdeb.net for inclusion in their archive,
along with some warning that it may not work on all system? Just a thought
though.

2008/1/25, Sergei Ivanov <email address hidden>:
>
> I did attach it! Maybe launchpad does not allow this via email.
> Now I am trying to do this using the web interface.
>
>
> ** Attachment added: "bootlogd_2.86.01.tar.gz (unofficial package)"
> http://launchpadlibrarian.net/11569042/bootlogd_2.86.01.tar.gz
>
> --
> logd not running
> https://bugs.launchpad.net/bugs/98955
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Gunnar Thielebein (lorem-ipsum)]

I hit a fast test and Sergei's version worked nicely.
I'll also try with 2.6.24 later on.

Now I can see bootlog of my headless server.
Hope this will get standalone package in the ubuntu repo.

Thanks, for that!

[Sergei Ivanov (svivanov)]

I am not willing to maintain it seriously, it is too system-dependent.
Nevertheless, here is a new version. Changes are:

- Improved logfile formatting.
- The logfile is renamed to /var/log/bootmsg, to avoid conflict with logd in the future.

Again, please do not install it blindly. You cannot be sure that I am not giving you a trojan.

[Pär Lidén (par-liden)]

Yes, I sure understand that you don't want to be a maintainer for it, that
would probably be quite a lot of work. For me the [ok] comes on it's own
separate:
Sun Jan 27 21:52:32 2008: * Starting system message bus dbus
Sun Jan 27 21:52:32 2008: [ OK ]

Is this intentional? Otherwise this seems much nicer than before.

Keep up the good work!

2008/1/26, Sergei Ivanov <email address hidden>:
>
> I am not willing to maintain it seriously, it is too system-dependent.
> Nevertheless, here is a new version. Changes are:
>
> - Improved logfile formatting.
> - The logfile is renamed to /var/log/bootmsg, to avoid conflict with logd
> in the future.
>
> Again, please do not install it blindly. You cannot be sure that I am
> not giving you a trojan.
>
>
> ** Attachment added: "bootlogd_2.86.02.tar.gz"
> http://launchpadlibrarian.net/11578525/bootlogd_2.86.02.tar.gz
>
> --
> logd not running
> https://bugs.launchpad.net/bugs/98955
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Sergei Ivanov (svivanov)]

> Yes, I sure understand that you don't want to be a maintainer for it, that
> would probably be quite a lot of work. For me the [ok] comes on it's own
> separate:
> Sun Jan 27 21:52:32 2008: * Starting system message bus dbus
> Sun Jan 27 21:52:32 2008: [ OK ]
>
> Is this intentional? Otherwise this seems much nicer than before.

Well, bootlogd *has* a maintainer, it's Debian sysvinit team. Maybe I'll send the fixes
there some day.

The OK placement is yes, sort of intentional. They use a lot of terminal trickery to make
output look better, and logging it correctly would require many changes to the code.
I had to choose from a couple of simple rules, and the other choices led to worse results.
After all, this "OK" is a separate message and its timing may be useful.

You can make it appear on the same line by changing the source as follows.
Go to bootlog.c line 361, there will be a part of switch like this:

case '\n':
case '\r":
   ...

Change it to:

case '\r':
    break;
case '\n':
   ...

(that is, interchange the two cases and insert "break;" between them).
But then you will lose, among other things, the summary of a long fsck run
(it will be truncated as a part of one extra long line).

[Pär Lidén (par-liden)]

Ok, I see. Well, then this behavior is probably preferred.

Thankyou

2008/1/27, Sergei Ivanov <email address hidden>:
>
> > Yes, I sure understand that you don't want to be a maintainer for it,
> that
> > would probably be quite a lot of work. For me the [ok] comes on it's own
> > separate:
> > Sun Jan 27 21:52:32 2008: * Starting system message bus dbus
> > Sun Jan 27 21:52:32 2008: [ OK ]
> >
> > Is this intentional? Otherwise this seems much nicer than before.
>
> Well, bootlogd *has* a maintainer, it's Debian sysvinit team. Maybe I'll
> send the fixes
> there some day.
>
> The OK placement is yes, sort of intentional. They use a lot of terminal
> trickery to make
> output look better, and logging it correctly would require many changes to
> the code.
> I had to choose from a couple of simple rules, and the other choices led
> to worse results.
> After all, this "OK" is a separate message and its timing may be useful.
>
> You can make it appear on the same line by changing the source as follows.
> Go to bootlog.c line 361, there will be a part of switch like this:
>
> case '\n':
> case '\r":
> ...
>
> Change it to:
>
> case '\r':
> break;
> case '\n':
> ...
>
> (that is, interchange the two cases and insert "break;" between them).
> But then you will lose, among other things, the summary of a long fsck run
> (it will be truncated as a part of one extra long line).
>
> --
> logd not running
> https://bugs.launchpad.net/bugs/98955
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[xenoson (xenoson)]

> Bootlogd [...] This is the right tool for the problem "what did that scrolled-away messages say?".

No Bootlog is really no big issue. It is just helpful for troubleshooting actual boot problems.
When you see a failed message scoll by just place a link to /sbin/sulogin in /etc/rcS.d or /etc/rc2.d shortly after the problematic script, ie.
sudo ln -s /sbin/sulogin /etc/rcS.d/S81prob
Probably it's wise to take away the 'quiet' and 'splash' kernel parameter the next boot.
The link will give you a root shell, then you can use the shift + PgUp to scoll back.

[Pev (pevik)]

Hi,

this might help:
https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/125710/comments/1

(from https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/125710)

[sefs (sefsinc)]

Sergei,

Can you give me layman steps of how to install your package?

Thanks.

[sefs (sefsinc)]

p.s. when i run make in the untared dir i get

gcc -Wall -O2 -D_GNU_SOURCE -s -lutil bootlogd.c -o bootlogd
bootlogd.c: In function ‘main’:
bootlogd.c:658: warning: pointer targets in passing argument 2 of ‘writelog’ differ in signedness

should i be concerned about that warning?

[Sergei Ivanov (svivanov)]

> Can you give me layman steps of how to install your package?

This is a Debian source package. It is meant to be installed using
dpkg-related tools, not with "make; make install".
A recipe was there in the post where I announced the package.
Here it is again:

 # unpack the source
tar xzvf bootlogd_2.86.02.tar.gz
 # build the package
cd bootlogd-2.86.02
debuild -us -uc -b
cd ..
 # install the package
sudo dpkg -i bootlogd_2.86.02_*.deb

As for the compilation warning, it looks harmless.

[Shirish Agarwal (shirishag75)]

Hi all,
 From whatever little I know of Upstart wasn't it designed to replace sysvinit in the first place.

Dunno if this is the right thing or not but from what I read it seems to say that Upstart is not able to play along nicely with logd or vice-versa.

I don't like the idea of using scripts or packages from other places which are not verified either from QA perspective or other things as well.

My issue is can we hope to see this issue resolved during the Intrepid cycle. I'll be hopping to the Intrepid cycle around the 24th-26th of this month till when the tool-chain would be done.

Looking forward for comments and suggestions on the same.

[Brando56894 (brando56894)]

i installed Sergei's version and it works but it only captures 3 seconds of my boot messages, how can i fix this?

[Sergei Ivanov (svivanov)]

> i installed Sergei's version and it works but it only captures 3 seconds
> of my boot messages, how can i fix this?

Is there a lot of text to capture? If so, it might overflow the internal 32K buffer.
It is defined on line 52 in bootlogd.c. Try to increase it.

Also, there is a stop-bootlogd script which stops bootlogd near the end of boot
sequence. Check when this script is run.

[Brando56894 (brando56894)]

thanks, how can i check to see when the script is run?

[Brando56894 (brando56894)]

making some progress, i increased it from 32k to 128k and it now logs 9 seconds. im going to go all out and up it to 1mb and see how that goes.

[Brando56894 (brando56894)]

i cant make the buffer big enough to log it all. my boot process takes 23 seconds and the biggest buffer that i can get to work is 975kb (999,999 bytes) which will only log 18 seconds. also is there a way to log the shutdown messages? network manager keeps giving me a lot of errors but i can never read them in time.

[Sergei Ivanov (svivanov)]

> i cant make the buffer big enough to log it all. my boot process takes
> 23 seconds and the biggest buffer that i can get to work is 975kb
> (999,999 bytes) which will only log 18 seconds.

This is a strange constant. The 32-bit integer overflows near 2Gb.
What is wrong with larger values? Doesn't the program compile,
or doesn't it start?

Do you measure the 18 seconds by the wall clock or by the timestamps
in the log file?

I'm not a great expert in bootlogd, but I thought that the internal buffer
is used until /var is writeable, then it writes directly to the file.

So if a buffer in bootlogd overflows *after* /var is made writeable,
then this is a bug in bootlogd. Otherwise there is no way other than
enlarging the buffer - it has to remember the messages somewhere
until the disk is ready.

> also is there a way to
> log the shutdown messages?

This is hard. You cannot save anything after the filesystems are unmounted.
I've heard of someone who used a video camera to record screen messages.

[Brando56894 (brando56894)]

when i place an integer value that is larger then six digits (largest i can go is 999,999) it compiles fine but just doesnt log anything. first i tried 1mb and that didnt work so i knocked it down to 999mb and that didnt work, so i used 999,999 and it worked. im measuring the time based on the timestamps in the log and i know it takes me 23 seconds to boot up because bootchart says so;.

as for the shutdown messages i can see how this could be a problem.

[Shirish Agarwal (shirishag75)]

Brando shouldn´t u have said 999kb not 999mb as you wrote above. Anybody having any idea as to whatś happening on this front atm.

[Brando56894 (brando56894)]

Good catch, thats what I meant.

[HousieMousie2 (housiemousie2)]

Kubuntu KDE 3.5.9 Hardy Heron (for pity sake, this has been a problem since Dapper, or so it seems when reading the Ubuntu Forums)

Bootlog remains empty, as others have stated... even after changing No to Yes.

The Boot Log in KSystemlog states that there no file 'boot.log' in /var/log.

Personal note:
This is highly annoying, particularly for newbies like myself and disconcerting to see red text go flying by upon boot, with no idea what it said. Not to mention that so many workarounds seem system 'sensitive.' Doesn't inspire me to go poking around at things I don't know how to fix if the workaround breaks something.

[Feanor (angelo-pantano)]

this bug persists on intrepid ibex

i cannot simply see my boot log (upstream, bootlog or whatever)

dmesg is NOT enough

[Johann SAUNIER (jsaunier.devel)]

It's a big issue for me, especialy on my headless server.

[Vincent Pluk (v-pluk)]

I would be very very nice if this issue could be solved.

[Sydoruk Yaroslav (lip)]

Description: Ubuntu jaunty (development branch)
Release: 9.04

confirm, this issue is still present

[Charles Atkinson (7-launchpad-catcons-co-uk)]

Hello :-)

Subject: bootlogd 2.86.02 boot script link change to capture more boot messages

Regards the workaround for this bug ('cos it ain't going away any time soon!).

After installing bootlogd 2.86.02 from the package Sergei attached to this bug report (thanks Sergei) ...

bootlogd is started by /etc/rcS.d/S12bootlogd which is a symbolic link to /etc/init.d/bootlogd. S12bootlogd is not the first S* entry in /etc/rcS.d/ so bootlogd does not catch output from earlier S* entries. On my system (ubuntu 8.04.2), boot messages from the following were not logged:

S01mountkernfs.sh
S01readahead
S02hostname.sh
S06keyboard-setup
S07linux-restricted-modules-common
S08hwclockfirst.sh
S08loopback
S10udev
S11hwclock.sh
S11mountdevsubfs.sh

Boot messages from the above can be logged by making bootlogd start before them. The following commands, run by root, will do the trick.

cd /etc/rcS.d
rm S12bootlogd
ln -s ../init.d/bootlogd S01bootlogd

I expected this change to cause some breakage; perhaps bootlogd depended on something set by the earlier boot scripts; why would the package designers not start it right at the beginning of the boot process so it could capture all the boot messages?

But it tested OK. YYMV. In case it does cause serious breakage it is prudent to ensure you can boot something else (ubuntu installation CD, Knoppix etc) and remove /etc/rcS.d/S01bootlogd if needs must.

Best

Charles

[Sergei Ivanov (svivanov)]

On Saturday 14 March 2009, Charles Atkinson wrote:
> I expected this change to cause some breakage; perhaps bootlogd depended
> on something set by the earlier boot scripts; why would the package
> designers not start it right at the beginning of the boot process so it
> could capture all the boot messages?

It may work or not depending on the system. The program uses
pseudo-terminals (PTYs). If you have BSD PTYs compiled in the kernel
and have static pty* devices in your root filesystem, then yes,
it should be possible to run bootlogd right from the beginning
(perhaps even from the initial ramdisk). If not, you have to wait until
/dev/pts is mounted by S11mountdevsubfs.sh.

Best regards,
Sergei

[Julio Pedreira (julio.pedreira)]

I can't make it work even with Sergei Ivanov's patched version. Im running Ubuntu 8.10 and have set BOOTLOGD_ENABLE=Yes in /etc/default/bootlogd ... this is a big issue, at least for me... I see boot scripts failing but can't find out which ones or why...

[Distro-jumper (boblounsbury)]

Just wanted to say that I installed Debian 5.0 a month ago and bootlogd worked perfectly by setting /etc/default/bootlogd to Yes. So, it's very strange that this seems to be such a large problem on my Ubuntu 8.04 server.

[Derek_ (derek-name)]

Thanks for the workaround, Sergei. I downloaded, built, and installed your 2.86.02 package above and got just what I needed. I'm using Hardy.

[Charles Atkinson (7-launchpad-catcons-co-uk)]

Hello (especially Sergei) :-)

I'm trying to go further, running bootlogd on ubuntu 8.04.02 running in a VirtualBox virtual machine with / mounted read-only and a writeable /var/log mounted later. Isn't it always the way -- the code works perfectly well and then someone shifts the goal posts?!

I do understand that I am on my own here and Sergei has said he is not supporting this "as is" version of bootlogd but a couple of pointers would help and I am happy to feed back my adventures in case anyone else is crazy enough to want to do the same thing.

Reviewing the code, the read-only / and a writeable /var/log appearing later should work OK -- if I understand the code correctly -- but it doesn't. bootlogd does start during boot but there's no /var/log/bootmsg file after booting.

A long time ago I was a fluent applications (not kernel) C programmer but it's rusty now so please allow for some ignorance.

In bootlogd.c, there is a while loop starting at line 585 and ending at line 664. Each iteration it reads from the intercepted console output, writes what it gets to the console and either buffers it or writes it to logfile. What is the access() function on line 643? Lines 648 and 651 try to open logfile in append mode, creating it if it does not exist. As I understand it this should fail until there is a writeable /var/log directory. If that is correct then it should work ... ?

Best

Charles

[Derek_ (derek-name)]

access() is from unistd.h.

Starting at line 250 of /usr/include/unistd.h:

/* Values for the second argument to access.
   These may be OR'd together. */
#define R_OK 4 /* Test for read permission. */
#define W_OK 2 /* Test for write permission. */
#define X_OK 1 /* Test for execute permission. */
#define F_OK 0 /* Test for existence. */

/* Test for access to NAME using the real UID and real GID. */
extern int access (__const char *__name, int __type) __THROW __nonnull ((1));

See http://kerneltrap.org/man/linux/man3p/access.3p

[Sergei Ivanov (svivanov)]

On Monday 27 April 2009, Charles Atkinson wrote:
> In bootlogd.c, there is a while loop starting at line 585 and ending at
> line 664.  Each iteration it reads from the intercepted console output,
> writes what it gets to the console and either buffers it or writes it to
> logfile.  What is the access() function on line 643?  Lines 648 and 651
> try to open logfile in append mode, creating it if it does not exist.
> As I understand it this should fail until there is a writeable /var/log
> directory.  If that is correct then it should work ... ?
>

I think it should work as you expect (but I never tried this kind of configuration).

Are you sure that it is non-writable /var that breaks it? For example, can you mount
root (with /var) read-write from the very beginning and see if this works?

Keep in mind that one of my patches changed the name of the log file,
it is /var/log/boot, not /var/log/bootmsg. Make sure this file exists or
call bootlogd with the -c option.

What is the status of bootlogd at the end of the boot sequence? Is it alive?
If yes, can you check what it is doing? What files it has opened (see /proc/*/fd)?

Does it work if started later? If yes, I suggest you bisect it and find the exact point
after which it starts working. It might be mounting of /dev, for example.

[Charles Atkinson (7-launchpad-catcons-co-uk)]

Thanks Derek and Sergei :-)

Mea culpa -- a simple touch /var/log/bootmsg after mounting the writeable /var did the trick.

I'm using bootlogd from http://launchpadlibrarian.net/11578525/bootlogd_2.86.02.tar.gz (hence bootmsg not boot).

Best

Charles

[Jean-Baptiste Quenot (jbq-caraldi)]

I was happily using bootlogd 2.86.02 until I upgraded to Jaunty: the package cannot be installed anymore, due to a conflict with initscripts:

Unpacking bootlogd (from .../bootlogd_2.86.02_amd64.deb) ...
dpkg: error processing /var/cache/apt/archives/bootlogd_2.86.02_amd64.deb (--unpack):
 trying to overwrite `/etc/default/bootlogd', which is also in package initscripts
Processing triggers for man-db ...
Errors were encountered while processing:
 /var/cache/apt/archives/bootlogd_2.86.02_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Any idea?

[glitsj16 (glitsj16)]

Hi Jean-Baptiste,

You can force dpkg to overwrite files by adding the --force-overwrite param to the command to install the bootlogd .deb:

sudo dpkg -i --force-overwrite bootlogd_2.86.02_*.deb

Tested this on jaunty and it produces a nice /var/log/bootmsg file.

Hope this helps,

glitsj16

[Scott James Remnant (Canonical) (canonical-scott)]

Note that bootlogd not working is a different bug on sysvinit (we should fix that)

[DaveM (davidmartin-ntlworld)]

The simplest solution I have found, which helped me work out what was wrong without installing unsupported packages, is to use Ctrl-S to pause the output and Ctrl-Z to let it start again. Hope it helps

[Charles Atkinson (7-launchpad-catcons-co-uk)]

This bug report, started on 2007-03-30, has been marked as a duplicate of https://bugs.launchpad.net/upstart/+bug/328881, started on 2009-02-13.

I understood that later bugs were marked as duplicates of earlier bugs; that way the activity is kept in one place.

[Dimitrios Symeonidis (azimout)]

@Charles Atkinson: not necessarily, the idea is that the master bug should be the one with the most details, or the one that received the most attention... Often it is the oldest one, but not always.

[Charles Atkinson (7-launchpad-catcons-co-uk)]

Thanks Dimitrios Symeonidis

That makes sense. If it were applied in this case then this bug report (with 74 comments) would be the master rather than https://bugs.launchpad.net/upstart/+bug/328881 (with three comments, two of which are mine relating to bug report duplication).

[Scott James Remnant (Canonical) (canonical-scott)]

On Sun, 2009-08-09 at 10:43 +0000, Charles Atkinson wrote:

> *** This bug is a duplicate of bug 328881 ***
> https://bugs.launchpad.net/bugs/328881
>
> Thanks Dimitrios Symeonidis
>
> That makes sense. If it were applied in this case then this bug report
> (with 74 comments) would be the master rather than
> https://bugs.launchpad.net/upstart/+bug/328881 (with three comments, two
> of which are mine relating to bug report duplication).
>
Seriously Charles, did you need to send *half a dozen* e-mails all on
the same subject?

Scott
--
Scott James Remnant
<email address hidden>

[Jarl (jarl-dk)]

@ Scott James Remnant

I believe Charles does not need to sending "half a dozen" emails, if he just get *one* reasonable answer as to why this bug is a duplicate of bug 328881 and not opposite.

To me it seems like this bug is the one with most details (most comments) and most attention (most subscribers).

Jarl

[Scott James Remnant (Canonical) (canonical-scott)]

On Wed, 2009-08-12 at 10:11 +0000, Jarl wrote:

> To me it seems like this bug is the one with most details (most
> comments) and most attention (most subscribers).
>
Age of bug, number of comments and most subscribers are *irrelevant*.

All that matters is that the bug subject and description most succinctly
describe the problem for the *developer* (ie. me)

Frankly, get a grip.

The bug is open, you're all arguing over who gets to be the original
reporter and spamming dozens of people's mailboxes about it; and wasting
theirs and my time.

Scott
--
Scott James Remnant
<email address hidden>