[Pkg-sysvinit-devel] Bug#354163: Getting the machine to power down?

[Andreas Tille]

On Tue, 12 Sep 2006, Petter Reinholdtsen wrote:

> Thank you.  The umounting of file systems are obviously not working as
> it should.  I read that from your shutdown load.
>
> Try replacing in /etc/init.d/umountfs the line saying
>
>  PATH=/usr/sbin:/usr/bin:/sbin:/bin
>
> with a line saying
>
>  PATH=/sbin:/bin:/usr/sbin:/usr/bin
>
> I am starting to suspect the problem is that you have one set of tools
> in /{s}bin/, and a different set of tools with the same names in
> /usr/{s}bin/.  Try also to add 'set -x' early in umountfs, to see what
> the script do when it fails.

/etc/init.d# diff -u umountfs.orig umountfs 
--- umountfs.orig       2006-01-22 20:50:11.000000000 +0100
+++ umountfs    2006-09-12 10:59:30.000000000 +0200
@@ -9,7 +9,8 @@
  # Description:
  ### END INIT INFO

-PATH=/usr/sbin:/usr/bin:/sbin:/bin
+set -x
+PATH=/sbin:/bin:/usr/sbin:/usr/bin
  . /lib/init/vars.sh

  . /lib/lsb/init-functions


You can beat me with a large club but there is no change at all in
the output.

> Your problem might also be related to the NFS mount points, and the
> fact that portmap is killed before nfs umounting is tried (bug
> #258420).  If this is the case, I am working on a fix.

The problem occures also on machines where actually no NFS mounts
are active and only are mounted at user request.  I could even
try to disable NFS completely on my laptop to verify whether it
has any connection to NFS.

> The shutdown sequence you typed in seem to jump from S30urandom
> directly to S90reboot without running S31umountnfs.sh, S32portmap,
> S35networking, S40umountfs and S60umountroot.  I fail to understand
> how that can happen.

It really seems to be the case.  At least there is no sign that
the changed umountfs is called at any time.

> It would be useful to have the output from a run with set -x as
> described above, but that will be quite a lot to type, so we can wait
> to see if the PATH changes help first.

Well, neither the PATH nor the -x showed any result.  My personal
way of debugging would be to revert the changes of initscripts_2.86.ds1-11
step by step and look what happens.  The problem is that I would
do this a little bit like monkey-typing and it might be that I
would come to wrong conclusions by reverting one diff that only
works if some other diff is not in place.  So my suggestion is:

Try to build a reasonable "intermediate diff" between ds1-10 and
ds1-11 and I will see what happens here.  If it works the problem
is in the other half of the diffs if it fails we are closer to
the problem and try another intermediate diff.  What about this?
(You notice the idea was born from the conditioning as experimental
physicis. ;-)) )

Kind regards

           Andreas.

-- 
http://fam-tille.de