Strange umount problem in latest 2.4.0 kernels

Strange umount problem in latest 2.4.0 kernels

[Udo A. Steinberg]

As previously reported by someone, there are occasional
problems when shutting down with unmounting partitions,
that are reported as busy for strange reasons.

Keith Owens said it was supposedly a Redhat shutdown
script issue and I since I'm not using Redhat, it's
most likely not that.

Upon fscking after reboot, I always have errors on a 
single inode and it's always the same one:

/dev/hdb1: Inode 522901, i_blocks is 64, should be 8. FIXED

Can someone tell me an easy and reliable way of figuring
out which file (program) uses said inode? I think that's
probably the key to figuring out why the partition is
busy on umount.

-Udo.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Strange umount problem in latest 2.4.0 kernels

[Daniel Phillips]

"Udo A. Steinberg" wrote:
> Upon fscking after reboot, I always have errors on a
> single inode and it's always the same one:
> 
> /dev/hdb1: Inode 522901, i_blocks is 64, should be 8. FIXED
> 
> Can someone tell me an easy and reliable way of figuring
> out which file (program) uses said inode? I think that's
> probably the key to figuring out why the partition is
> busy on umount.

ls -iR | grep 12345

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Strange umount problem in latest 2.4.0 kernels

[Alexander Viro]

On Thu, 11 Jan 2001, Daniel Phillips wrote:

> "Udo A. Steinberg" wrote:
> > Upon fscking after reboot, I always have errors on a
> > single inode and it's always the same one:
> > 
> > /dev/hdb1: Inode 522901, i_blocks is 64, should be 8. FIXED
> > 
> > Can someone tell me an easy and reliable way of figuring
> > out which file (program) uses said inode? I think that's
> > probably the key to figuring out why the partition is
> > busy on umount.
> 
> ls -iR | grep 12345

find `mount | grep hdb1 | cut -f3 -d' '` -inum 522901 -xdev

- no need to walk through all filesystems.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Strange umount problem in latest 2.4.0 kernels

[Udo A. Steinberg]

> /dev/hdb1: Inode 522901, i_blocks is 64, should be 8. FIXED

Ok, culprit identified: /var/spool/lpd/lpd.lock

On another partition I had the same problem with httpd's
error_log.

Since both of those seem to be log- and lock-files, maybe
there's something wrong with file locking?

Anyway, disabled both lpd and httpd from the startup scripts
and now the bug is triggered *every* time. I cannot reboot
a single time without partitions being busy. When neither
lpd nor httpd run, fsck finds nothing wrong.

The very strange stuff is umount at reboot:

umount: none busy - remounted read-only
umount: /: device is busy
Remounting root-filesystem read-only
mount: / is busy
Rebooting.

*fsck*

The "none" bit puzzles me the most. /etc/fstab and /etc/mtab
look perfectly ok.

Has anyone got an idea? Everything worked well with 2.4.0 and
Alan's tree up to -ac4, didn't try ac5, and ac6 is what messes
up now.

-Udo.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Strange umount problem in latest 2.4.0 kernels

[Alexander Viro]

On Thu, 11 Jan 2001, Udo A. Steinberg wrote:

> > /dev/hdb1: Inode 522901, i_blocks is 64, should be 8. FIXED

> umount: none busy - remounted read-only
 
> The "none" bit puzzles me the most. /etc/fstab and /etc/mtab
> look perfectly ok.
> 
> Has anyone got an idea? Everything worked well with 2.4.0 and
> Alan's tree up to -ac4, didn't try ac5, and ac6 is what messes
> up now.

Try to revert to -ac4 fs/super.c and see if it helps

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Strange umount problem in latest 2.4.0 kernels

[Udo A. Steinberg]

Alexander Viro wrote:

> > umount: none busy - remounted read-only
> 
> > The "none" bit puzzles me the most. /etc/fstab and /etc/mtab
> > look perfectly ok.
> >
> > Has anyone got an idea? Everything worked well with 2.4.0 and
> > Alan's tree up to -ac4, didn't try ac5, and ac6 is what messes
> > up now.
> 
> Try to revert to -ac4 fs/super.c and see if it helps

That makes no difference. Still acting weird. Must be something
else.

-Udo.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Strange umount problem in latest 2.4.0 kernels

[Udo A. Steinberg]

"Udo A. Steinberg" wrote:
> 
> The very strange stuff is umount at reboot:
> 
> umount: none busy - remounted read-only
> umount: /: device is busy
> Remounting root-filesystem read-only
> mount: / is busy
> Rebooting.

I just noticed another strange effect:

ps uxa misses a couple dozen processes. Effectively I'm seeing
only the kernel processes, all gettys, rpc.portmap, bash and ps.
All other processes, all daemons etc. are invisible. If I kill
portmap another process becomes visible.

I've checked a couple of other machines, different setups etc.
all with -ac6 and all show this behavior - also the umount stuff.

-Udo.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Strange umount problem in latest 2.4.0 kernels

[Alan Cox]

> I've checked a couple of other machines, different setups etc.
> all with -ac6 and all show this behavior - also the umount stuff.

Wait for -ac7 and see if that fixes it. I think I know whats up there

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Strange umount problem in latest 2.4.0 kernels

[Andreas Dilger]

Udo, you write:
> Anyway, disabled both lpd and httpd from the startup scripts
> and now the bug is triggered *every* time. I cannot reboot
> a single time without partitions being busy. When neither
> lpd nor httpd run, fsck finds nothing wrong.
> 
> The very strange stuff is umount at reboot:
> 
> umount: none busy - remounted read-only
          ^^^^
Check the output of "mount" and/or your /etc/fstab for a device called
"none".  On my system, there is devpts which has device "none", so it
is possible this is busy, and can't be unmounted, and hence root is also
busy and can't be ro remounted.  Maybe also check /proc/mounts for "none".

> umount: /: device is busy
> Remounting root-filesystem read-only
> mount: / is busy
> Rebooting.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Strange umount problem in latest 2.4.0 kernels

[Andries.Brouwer]

> The "none" bit puzzles me the most.

It is a common misconfiguration. Given a line

  device  dir  type  options  garbage

in /etc/fstab, some umount versions will complain "device busy"
when the umount fails. Thus, it is better to use

  proc    /proc     proc
  devpts  /dev/pts  devpts

instead of

  none    /proc     proc
  none    /dev/pts  devpts

so as to avoid this silly "none busy".
But many distributions come misconfigured like this.

These days umount is done by directory, not by device,
since a device may be mounted multiple times, so
I expect the silly message is gone.
(Is your umount recent?)

[But this is only about the "none". I don't know what is
wrong in your situation.]

Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Strange umount problem in latest 2.4.0 kernels

[Udo A. Steinberg]

Andries.Brouwer@cwi.nl wrote:
> 
> These days umount is done by directory, not by device,
> since a device may be mounted multiple times, so
> I expect the silly message is gone.
> (Is your umount recent?)
> 
> [But this is only about the "none". I don't know what is
> wrong in your situation.]

My umount is 2.10r. Alan says he knows what is wrong,
so we're all curiously expecting -ac7 ;)

-Udo.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Strange umount problem in latest 2.4.0 kernels

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]

"Udo A. Steinberg" wrote:

> "Udo A. Steinberg" wrote:
> >
> > The very strange stuff is umount at reboot:
> >
> > umount: none busy - remounted read-only
> > umount: /: device is busy
> > Remounting root-filesystem read-only
> > mount: / is busy
> > Rebooting.

Are you using devfs and do kernel threads have /dev/initctl open?

# lsof /dev
COMMAND     PID USER   FD   TYPE DEVICE SIZE NODE NAME
init          1 root   10u  FIFO    0,5       574 /dev/initctl
keventd       2 root   10u  FIFO    0,5       574 /dev/initctl
kapm-idle     3 root   10u  FIFO    0,5       574 /dev/initctl
kswapd        4 root   10u  FIFO    0,5       574 /dev/initctl
kreclaimd     5 root   10u  FIFO    0,5       574 /dev/initctl
bdflush       6 root   10u  FIFO    0,5       574 /dev/initctl
kupdate       7 root   10u  FIFO    0,5       574 /dev/initctl
i2oevtd       8 root   10u  FIFO    0,5       574 /dev/initctl
i2oblock      9 root   10u  FIFO    0,5       574 /dev/initctl
khubd        12 root   10u  FIFO    0,5       574 /dev/initctl
khttpd       16 root   10u  FIFO    0,5       574 /dev/initctl

-d


[-- Attachment #2: Card for David Ford --]
[-- Type: text/x-vcard, Size: 274 bytes --]

begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
url:www.blue-labs.org
adr:;;;;;;
version:2.1
email;internet:david@blue-labs.org
title:Blue Labs Developer
note;quoted-printable:GPG key: http://www.blue-labs.org/david@nifty.key=0D=0A
x-mozilla-cpt:;9952
fn:David Ford
end:vcard

Re: Strange umount problem in latest 2.4.0 kernels

[J . A . Magallon]

On 2001.01.11 Andries.Brouwer@cwi.nl wrote:
> > The "none" bit puzzles me the most.
> 
> It is a common misconfiguration. Given a line
> 
>   device  dir  type  options  garbage
> 
> in /etc/fstab, some umount versions will complain "device busy"
> when the umount fails. Thus, it is better to use
> 
>   proc    /proc     proc
>   devpts  /dev/pts  devpts
> 
> instead of
> 
>   none    /proc     proc
>   none    /dev/pts  devpts
> 
> so as to avoid this silly "none busy".
> But many distributions come misconfigured like this.
> 

Same cam be applied to shm ? Thus kernel Documentation/Changes should be
changed:

System V shared memory is now implemented via a virtual filesystem.
You do not have to mount it to use it. SYSV shared memory limits are
set via /proc/sys/kernel/shm{max,all,mni}.  You should mount the
filesystem under /dev/shm to be able to use POSIX shared
memory. Adding the following line to /etc/fstab should take care of
things:

none        /dev/shm    shm     defaults    0 0

to

shm        /dev/shm    shm     defaults    0 0


-- 
J.A. Magallon                                                      $> cd pub
mailto:jamagallon@able.es                                          $> more beer

Linux werewolf 2.4.0-ac5 #1 SMP Wed Jan 10 23:36:11 CET 2001 i686

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Strange umount problem in latest 2.4.0 kernels

[Christoph Rohland]

On Fri, 12 Jan 2001, jamagallon@able.es wrote:
> Same cam be applied to shm ? Thus kernel Documentation/Changes
> should be changed:
[...]
> 
> none        /dev/shm    shm     defaults    0 0
> 
> to
> 
> shm        /dev/shm    shm     defaults    0 0
> 

Yes, I thought that I changed that :-( I always have the type as
device in my fstab. 

Linus, it is not really crucial, but still could be applied without
breaking anything for sure ;-) 

Greetings
		Christoph

--- 2.4.0/Documentation/Changes Mon Jan  1 19:00:04 2001
+++ linux/Documentation/Changes Fri Jan 12 09:03:35 2001
@@ -121,7 +121,7 @@
 memory. Adding the following line to /etc/fstab should take care of
 things:
 
-none           /dev/shm        shm             defaults        0 0
+shm            /dev/shm        shm             defaults        0 0
 
 Remember to create the directory that you intend to mount shm on if
 necessary (The entry is automagically created if you use devfs). You           
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/