DuckCorp » DuckCorp Infrastructure

I had a look at this issue. Considering that, insserv is not the default AFAIK and that bootlogd init script is executed before mountall.sh (/etc/rcS.d/S04bootlogd and /etc/rcS.d/S09mountall.sh respectively), I don't even understand how it was supposed to work before when having a separate /var mount point... Any idea?

A possible workaround for this issue would be to mount /var through initrd and thus by using initramfs-tools (existing configuration for mount root partition can be found in /usr/share/initramfs-tools/init and /usr/share/initramfs-tools/scripts/local).

I might understand what could be the issue after looking again at bootlogd manpage. Apparently, there is an -c option:

Attempt to write to the logfile even if it does not yet exist. Without this option, bootlogd will wait for the logfile to appear before attempting to write to it. This behavior prevents bootlogd from creating logfiles under mount points.

As this option is the defaut in /etc/init.d/bootlogd, it should work unless there is already /var/log/bootlogd before mounting /var. Therefore, deleting the file under the mount point should work, if not, it means there is a bug in -c option (maybe possible considering that it was working before)... I will test that this evening...

I just had a look and you're right, log/boot already exists in the /var partition (without mounting /var/log).

We should then check all machines and cleanup if necessary, and test a reboot if possible to confirm. And we should update the Debian BR too.

Maybe this option was added at some time, and in earlier versions /var/log/boot was created before /var/log being mounted, thus creating this situation.

Sorry, didn't read carefully the manpage before posting my previous message, as it states that if the option -c is present, then the log file will be written even if it does not exist yet. However, as -c is the default, then it will always be written under the mount point.

Thus a workaround I have just tested is to:

1. Remove existing /var/log/boot under the mount point.
2. Do not start bootlogd with -c by removing it from /etc/init.d/bootlogd.

Then it's working well. After reading quickly the changelog of the package, it seems that bootlogd has been moved up and down the init sequence, so the -c option could have been left behind in the process.

BTW, do you know approximatively when it stopped working in order to look when the regression happened exactly?

Patch sent to Debian BTS.