Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

A regular filesystem check on a Debian Lenny system triggered an fsck, and that nuked a handful of links in the /etc/rc?.d hierarchy (unfortunately I didn't keep a list).

The system seems to boot and run normally, but I'm worried its storing up trouble for the future.

Is there an easy (fairly automatic) way of rebuilding this piece of the system ? As I understand it, the links are generally manipulated by package postinst scripts using update-rc.d (and I haven't made any changes from the installed defaults).

Without any better ideas, my plan is one of:

  • Diff a listing with another similar system to identify which packages need their links repairing.
  • Wait until the system is upgraded to Squeeze (hopefully not too long :^) and assume the mass package upgrade will restore all the missing links.
share|improve this question
Restore from backup. – John Gardeniers Apr 18 '10 at 11:10
Yup, that'll teach me. All the data on the machine is regularly backed up, but the system and its config isn't, I think the original justification being that the system is so unmodified from a standard debian install that reinstalling packages or the system would be the easiest way to fix any damage. Unfortunately the rc?.d area turns out to be a bit more complicated so I think it's time to reconsider this policy... – timday Apr 18 '10 at 22:00
up vote 2 down vote accepted

If you do not have backups, you could try installing rcconf and see if it will re-create the links. But in reality all Debian init files would have following information at the top of each script:

# Provides:          inetd
# Required-Start:    $local_fs $remote_fs
# Required-Stop:     $local_fs $remote_fs
# Should-Start:      $syslog
# Should-Stop:       $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start or stop the xinetd daemon.

Based on this information alone you could partially restore everything with some basic shell scripting.

# Default-Start: 2 3 4 5 tells you that the Start symlinks to this init script should go into /etc/init{2,3,4,5}.d/S<XX>blah.

# Default-Stop: 0 1 6 means that Kill links do into/etc/init{0,1,6}.d/K<XX>blah.

The problem here is the <XX> part. This is the order your processes start and stop, so if you do not know the order, you could potentially end up with a hung boot. For example when you are trying to start NFS before the Networking.

share|improve this answer
Thanks for the rcconf tip. Used it to update all links; it got confused by the damaged ones and mapped them to K00 at all runlevels. Removing those and trying again, it creates the correct links. There was also some damage in rc.S (which rcconf doesn't seem to touch), but simply reinstalling initscripts fixed all those. – timday Apr 18 '10 at 21:41

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.