Bug 290477 – Link count on /var/lib/init.d is MAXINT after reboot

• Product: Gentoo Linux
• Status: RESOLVED NEEDINFO

[Description Phil Stracchino (Unix Ronin) 2009-10-25 17:59:29 UTC]

There is an intermittent bug which is causing the link count on /var/lib/init.d to be erroneously set to 4294967293.  I don't know for certain yet whether this is happening during rebooting the machine, or prior to reboot, but no symptoms are apparent until the system is rebooted.  After reboot, of course, boot fails because nothing can be written to /var/lib/init.d.

Either of the two following workarounds will allow rebooting the system successfully:
(a) Rename /var/lib/init.d, create a new /var/lib/init.d, move old contents into the new directory, reboot
(b) Copy (cp -a) /var/lib/init.d to a new directory, rename the old and new directories, reboot

The problem does not occur on every reboot.  I have found no pattern yet except that it is more likely to occur if the system has been up for at least several days.

Reproducible: Sometimes

Steps to Reproduce:
1.  Reboot the machine, preferably after at least several days of uptime.  If boot fails with multiple services failing to start, login as root and check link count on /var/lib/init.d.

Actual Results:  
On some reboots, for no apparent reason, the link count on /var/lib/init.d will be 4294967293.  The directory still only contains eleven items, though.  Contents of the directory after logging in single-user, and before fixing, are:

daemons/  depcache  deptree  inactive/  options/  snapshot/  softlevel  started/  starting/  stopping/  wasinactive/



The one Gentoo machine I currently have set up uses JFS on the disk.  Another previous "sandbox" machine, which I think I had set up with XFS, did not manifest the problem.  This raises the possibility that the bug is JFS-related.  However, I don't buy it as a filesystem error because it's always the same directory, /var/lib/init.d, never any other.  If it were a filesystem bug, it would be an improbably selective one.  At boot time, fsck.jfs always reports the filesystem as clean even when the bug manifests.  I don't rule out the possibility that there is a bug in fsck.jfs that is failing to report the error, or even conceivably causing it.

[Comment 1 Patrick Lauer 2009-12-30 12:51:46 UTC]

No idea how to reproduce or fix this :(

[Comment 2 Phil Stracchino (Unix Ronin) 2010-01-01 04:30:18 UTC]

Damned if I can reproduce it on demand either.  If I could, it might give me some tiny clue about where the problem lies.  It hasn't shown up in a couple of months now, so may even be fixed.  About the only diagnostic I've been able to think of is to "ls -ld /var/lib/init.d >> /etc/dircount.log" on every shutdown and boot at the last possible moment before umounting and the first possible moment after remounting rw, to at least tell me whether it's happening before shutdown or on reboot.

But yeah, I hear you; if I knew a way to reproduce it...