Am Donnerstag, 23. August 2007 02:06 schrieb Douglas A. Tutty:
> On Wed, Aug 22, 2007 at 10:33:09PM +0200, Rainer Dorsch wrote:
> > when shutting down my etch system, I get a
> >
> > umount /var: Device busy
> > Failed
> >
> > During the next reboot the /var partition is checked, but there is never
> > an inconsistency found, looks like the partition is at least synced
> > during shutdown.
> >
> > The only uncommon thing at this system, I remember:
> > I upgraded the system twice from woody to sarge and recently from sarge
> > to etch, though I am not sure if the problem came with the upgrade.
> >
> > Does anybody have an idea how I could find out why the device is busy?
>
> As root:
>
> ~#cp /usr/bin/lsof .
>
> So you can run this command with /usr/ unmounted.
>
> Run the /etc/rc0.d scripts manually in order K** before S** giving each
> the parameter Stop.
>
> Just before running S40umountfs, type
>
> ~#./lsof
>
> and see what files are still open.
>
> Then run S40umountfs and watch.
>
> If there is an error again as you describe,
>
> ~#./lsof
>
> To see what is still open.
>
> The result may provide some clew.
Many thanks for your response. I added the lsof commands
to /etc/init.d/umountfs
[EMAIL PROTECTED]:~$ diff -u /etc/init.d/umountfs.orig /etc/init.d/umountfs
--- /etc/init.d/umountfs.orig 2007-08-23 23:22:27.000000000 +0200
+++ /etc/init.d/umountfs 2007-08-24 19:57:38.000000000 +0200
@@ -157,7 +157,11 @@
exit 3
;;
stop)
+ lsof /var | tee /lsof.log
+ sleep 10
do_stop
+ lsof /var | tee /lsof2.log
+ sleep 10
;;
*)
echo "Usage: $0 start|stop" >&2
Unfortunately this does not give me any clue:
[EMAIL PROTECTED]:~$ cat /lsof.log
[EMAIL PROTECTED]:~$ cat /lsof2.log
[EMAIL PROTECTED]:~$
Are there other reasons than an open file, why a partition will not umount?
> If /var/ won't unmount, before continuing with the shutdown process:
>
> ~#umount -r /var
>
> This may work to remount /var in read-only.
>
Have not yet tried that, but as another data point, I noticed that the problem
does not show up on every shutdown, only sometimes, but I cannot see any rule
when this happens.
Many thanks,
Rainer
--
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: [EMAIL PROTECTED]
jabber: [EMAIL PROTECTED]
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/
