[lug] Unable to cleanly reboot

[J. Wayde Allen]

On Thu, 18 Oct 2001, Michael Deck wrote:

> First I did "init 3" which sent me back to a command-line prompt.

This is probably good.

> At that run level a lot of stuff was still in use but there were a
> number of services that I saw I didn't want or need on this machine so
> I killed them and took them out of chkconfig.

Not sure what this operation gained you, other than maybe you know that
these things weren't causing the lockup.  However, that kind of depends on
how you went about killing these processes?  I'm not familiar with
chkconfig is this a RedHat utility (I'm mostly a Debian user).

> Then I did "init 2" and that killed a few more services. I did lsof on
> all the partitions again and, after killing some services manually,
> saw that only 'login', 'bash', and 'lsof' were using files on
> /dev/hda6. I assumed that was OK and did "init 1" that froze the
> system.  It told me it had stopped the random service and eth0
> successfully, then 'no more processes in this runlevel" and it's once
> again time for a hard restart and fsck.

You might want to take a look at /etc/init.d and the /etc/rc?.d
directories.  The scripts that start and stop the services should be
located in /etc/init.d .  The /etc/rc1.d directory should contain symbolic
links to the scripts in /etc/init.d and these will look something like:

   K90sysklogd	K11cron     K20exim        K20inetd    K20makedev
   S20single

Any link starting with a K is a link to an /etc/init.d script to stop it
and links starting with the S are those that call one of the /etc/init.d
scripts to start it.  The numbers are more or less arbitrary, but do
indicate the relative order of precedence.  In the example above the cron
process (K11cron) would die first, then exim, inetd, and makedev.  I
think that the single user script would execute with the same priority S20
as all of the K20 processes, and the last thing would be to kill sysklogd
(K90).

The important thing is that the rc?.d directories tell you what is started
and stopped in each run level, and to some extent in what order.  You
could run each of these by hand as:

   /etc/indit.d scriptname start|stop

That should help you isolate the problem to an /etc/init.d script.  You'd
then need to go read the script and see what it is actually doing.

If you try killing things using the kill command you may not be doing the
same thing as the start/stop scripts.

- Wayde
  (wallen at lug.boulder.co.us)