Hello,
I've noticed in kernel 2.4.18 that my loop module remains busy after I umount the device using it. For example
mount -t iso9660 -o loop file.iso /mnt
* loop module gets loaded
* lsmod shows "loop 7952 1 (autoclean)"
* ps ax shows [loop0] process
then
umount /mnt
lsmod shows the same thing - specifically the use of loop as 1 and the [loop0] process remains open. Trying to rmmod loop gives me a device or resource busy error.
lsof gives the following output:
loop0 3765 root cwd DIR 8,1 4096 2 /
loop0 3765 root rtd DIR 8,1 4096 2 /
So I'm wondering why the loop module still remains in use after I umount the file that required it? Should it stay in use? Is there a way to change that behavoir or be able to rmmod the module without a reboot?
(Please CC replies to me personally)
Thank You
Kareem
On Wed, 24 Jul 2002, Kareem Dana wrote:
> Hello,
>
> I've noticed in kernel 2.4.18 that my loop module remains busy after
> I umount the device using it. For example
>
> mount -t iso9660 -o loop file.iso /mnt
> * loop module gets loaded
> * lsmod shows "loop 7952 1 (autoclean)"
> * ps ax shows [loop0] process
>
On Linux-2.4.18 there is no such problem here.
Script started on Wed Jul 24 15:13:59 2002
# lsmod
Module Size Used by
st 29272 0 (autoclean) (unused)
nfs 46836 0 (autoclean)
lockd 36988 0 (autoclean) [nfs]
sunrpc 62812 0 (autoclean) [nfs lockd]
ipchains 33624 6
ipx 18724 0 (unused)
3c59x 27968 1 (autoclean)
nls_cp437 4472 4 (autoclean)
isofs 17200 0 (unused)
loop 8472 0
sr_mod 11932 0 (unused)
cdrom 27808 0 [sr_mod]
BusLogic 35768 7
sd_mod 10104 14
scsi_mod 51740 4 [st sr_mod BusLogic sd_mod]
# mount -o loop raw.bin /mnt
# lsmod
Module Size Used by
st 29272 0 (autoclean) (unused)
nfs 46836 0 (autoclean)
lockd 36988 0 (autoclean) [nfs]
sunrpc 62812 0 (autoclean) [nfs lockd]
ipchains 33624 6
ipx 18724 0 (unused)
3c59x 27968 1 (autoclean)
nls_cp437 4472 4 (autoclean)
isofs 17200 0 (unused)
loop 8472 3
sr_mod 11932 0 (unused)
cdrom 27808 0 [sr_mod]
BusLogic 35768 7
sd_mod 10104 14
scsi_mod 51740 4 [st sr_mod BusLogic sd_mod]
# ls /mnt
boot.b initrd-2.4.18 map message vmlinuz-2.4.18
# umount /mnt
# lsmod
Module Size Used by
st 29272 0 (autoclean) (unused)
nfs 46836 0 (autoclean)
lockd 36988 0 (autoclean) [nfs]
sunrpc 62812 0 (autoclean) [nfs lockd]
ipchains 33624 6
ipx 18724 0 (unused)
3c59x 27968 1 (autoclean)
nls_cp437 4472 4 (autoclean)
isofs 17200 0 (unused)
loop 8472 0
sr_mod 11932 0 (unused)
cdrom 27808 0 [sr_mod]
BusLogic 35768 7
sd_mod 10104 14
scsi_mod 51740 4 [st sr_mod BusLogic sd_mod]
# rmmod loop
# lsmod
Module Size Used by
st 29272 0 (autoclean) (unused)
nfs 46836 0 (autoclean)
lockd 36988 0 (autoclean) [nfs]
sunrpc 62812 0 (autoclean) [nfs lockd]
ipchains 33624 6
ipx 18724 0 (unused)
3c59x 27968 1 (autoclean)
nls_cp437 4472 4 (autoclean)
isofs 17200 0 (unused)
sr_mod 11932 0 (unused)
cdrom 27808 0 [sr_mod]
BusLogic 35768 7
sd_mod 10104 14
scsi_mod 51740 4 [st sr_mod BusLogic sd_mod]
# mount -o loop raw.bin /mnt
# lsmod
Module Size Used by
loop 8568 3 (autoclean)
st 29272 0 (autoclean) (unused)
nfs 46836 0 (autoclean)
lockd 36988 0 (autoclean) [nfs]
sunrpc 62812 0 (autoclean) [nfs lockd]
ipchains 33624 6
ipx 18724 0 (unused)
3c59x 27968 1 (autoclean)
nls_cp437 4472 4 (autoclean)
isofs 17200 0 (unused)
sr_mod 11932 0 (unused)
cdrom 27808 0 [sr_mod]
BusLogic 35768 7
sd_mod 10104 14
scsi_mod 51740 4 [st sr_mod BusLogic sd_mod]
# umount /mnt
# lsmod
Module Size Used by
loop 8568 0 (autoclean)
st 29272 0 (autoclean) (unused)
nfs 46836 0 (autoclean)
lockd 36988 0 (autoclean) [nfs]
sunrpc 62812 0 (autoclean) [nfs lockd]
ipchains 33624 6
ipx 18724 0 (unused)
3c59x 27968 1 (autoclean)
nls_cp437 4472 4 (autoclean)
isofs 17200 0 (unused)
sr_mod 11932 0 (unused)
cdrom 27808 0 [sr_mod]
BusLogic 35768 7
sd_mod 10104 14
scsi_mod 51740 4 [st sr_mod BusLogic sd_mod]
# rmmod loop
# exit
Script done on Wed Jul 24 15:15:49 2002
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.
On Wed, 24 Jul 2002 14:59:19 -0400
Kareem Dana <[email protected]> wrote:
> Hello,
>
> I've noticed in kernel 2.4.18 that my loop module remains busy after I
> umount the device using it. For example
>
> mount -t iso9660 -o loop file.iso /mnt
> * loop module gets loaded
> * lsmod shows "loop 7952 1 (autoclean)"
> * ps ax shows [loop0] process
>
> then
> umount /mnt
> lsmod shows the same thing - specifically the use of loop as 1 and the
> [loop0] process remains open. Trying to rmmod loop gives me a device
> or resource busy error.
For some reason or other, umount didn't losetup -d the device.
Try losetup -d /dev/loop0, and see whether it does what you want, or
returns some sort of error.
--hobbs
On Wed, 24 Jul 2002 15:33:19 -0400
Kareem Dana <[email protected]> wrote:
> Andrew Rodland <[email protected]> wrote:
> > Kareem Dana <[email protected]> wrote:
> >
> > > Hello,
> > >
> > > I've noticed in kernel 2.4.18 that my loop module remains busy
> > > after I umount the device using it. For example
> > >
> > > mount -t iso9660 -o loop file.iso /mnt
> > > * loop module gets loaded
> > > * lsmod shows "loop 7952 1 (autoclean)"
> > > * ps ax shows [loop0] process
> > >
> > > then
> > > umount /mnt
> > > lsmod shows the same thing - specifically the use of loop as 1 and
> > > the[loop0] process remains open. Trying to rmmod loop gives me a
> > > device or resource busy error.
> >
> > For some reason or other, umount didn't losetup -d the device.
> >
> > Try losetup -d /dev/loop0, and see whether it does what you want, or
> > returns some sort of error.
> >
> > --hobbs
> losetup worked like a charm. Thanks. Any reason umount would not do
> that automatically though? umount -V returns umount: mount-2.11r
No idea, although I can't claim to be an expert. I have mount-2.11h,
and it seems to do it automatically for me.
On Wed, 24 Jul 2002 15:19:04 -0400
Andrew Rodland <[email protected]> wrote:
> On Wed, 24 Jul 2002 14:59:19 -0400
> Kareem Dana <[email protected]> wrote:
>
> > Hello,
> >
> > I've noticed in kernel 2.4.18 that my loop module remains busy after I
> > umount the device using it. For example
> >
> > mount -t iso9660 -o loop file.iso /mnt
> > * loop module gets loaded
> > * lsmod shows "loop 7952 1 (autoclean)"
> > * ps ax shows [loop0] process
> >
> > then
> > umount /mnt
> > lsmod shows the same thing - specifically the use of loop as 1 and the
> > [loop0] process remains open. Trying to rmmod loop gives me a device
> > or resource busy error.
>
> For some reason or other, umount didn't losetup -d the device.
>
> Try losetup -d /dev/loop0, and see whether it does what you want, or
> returns some sort of error.
>
> --hobbs
umount: mount-2.11r
losetup worked like a charm. Thanks. Any reason umount would not do that automatically though?
umount -V returns umount: mount-2.11r
- Kareem
On Wed, Jul 24, 2002 at 03:33:19PM -0400, Kareem Dana wrote:
> losetup worked like a charm. Thanks. Any reason umount would not do that automatically though?
Read mount(8), the places where losetup is mentioned.
On Wed, 24 Jul 2002, Andries Brouwer wrote:
> On Wed, Jul 24, 2002 at 03:33:19PM -0400, Kareem Dana wrote:
>
> > losetup worked like a charm. Thanks. Any reason umount would not do that automatically though?
>
> Read mount(8), the places where losetup is mentioned.
It works in my system and `umount` is version 2.10o
umount: umount-2.10o
It works because (strace output), umount does the LOOP_CLR_FD ioctl().
munmap(0x400aa000, 4096) = 0
oldumount("/mnt") = 0
open("/dev/loop0", O_RDONLY) = 3
ioctl(3, LOOP_CLR_FD, 0) = 0
close(3) = 0
If you don't have such an `umount`, loop will remain active, preventing
the module from being unloaded.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.
On Wed, 24 Jul 2002 21:41:30 +0200
Andries Brouwer <[email protected]> wrote:
> On Wed, Jul 24, 2002 at 03:33:19PM -0400, Kareem Dana wrote:
>
> > losetup worked like a charm. Thanks. Any reason umount would not do that automatically though?
>
> Read mount(8), the places where losetup is mentioned.
I compiled my system from scratch following the guide of the LFS. LFS recommends that you create a symbolic link from /proc/mounts to /etc/mtab. After reading the mount man page, that seems to be my problem. mtab shouldnt be a symlink. Thanks for the help. I'm going to e-mail the LFS mailing list about their mtab symlink now
On Wed, Jul 24, 2002 at 04:03:29PM -0400, Richard B. Johnson wrote:
> > Read mount(8), the places where losetup is mentioned.
>
> It works in my system and `umount` is version 2.10o
> It works because (strace output), umount does the LOOP_CLR_FD ioctl().
Why do you repeat an imprecise answer? Read mount(8).
On Wed, 24 Jul 2002, Andries Brouwer wrote:
> On Wed, Jul 24, 2002 at 04:03:29PM -0400, Richard B. Johnson wrote:
>
> > > Read mount(8), the places where losetup is mentioned.
> >
> > It works in my system and `umount` is version 2.10o
> > It works because (strace output), umount does the LOOP_CLR_FD ioctl().
>
> Why do you repeat an imprecise answer? Read mount(8).
Hardly imprecise. "Read mount(8)..." From what distribution? I gave
the precise reason why umount 2.10o works, not some wise-guy retort
that presumes that everybody has some specific distribution with
your version of man pages.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.