Bug 141948 - Loopback devices are not being freed on RHEL2.1ES
Loopback devices are not being freed on RHEL2.1ES
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: nautilus (Show other bugs)
2.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Alexander Larsson
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-06 05:47 EST by Issue Tracker
Modified: 2015-01-07 19:09 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-08 10:19:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Issue Tracker 2004-12-06 05:47:07 EST
Escalated to Bugzilla from IssueTracker
Comment 1 Alexander Larsson 2004-12-06 18:48:23 EST
How are loopback devices related to nautilus?
Comment 2 Nick Strugnell 2004-12-07 04:48:48 EST
Its described in the related issue.

Although I don't think that escalation from IT to BZ is working - I escalated
this from IT to BZ and it doesn't seem to have done anything except copy the
title of the IT.

Any clues on how to get the escalation to actually work properly?
Comment 3 Alexander Larsson 2004-12-07 10:27:20 EST
There is no reference to an IssueTracker number that i can see, and i don't have
an IssueTracker account. Nor am i supposed to need one i've been told.
Comment 4 Nick Strugnell 2004-12-07 10:54:28 EST
Obviously a feature :-)

Cut and paste from the IT below:

 Running RHEL2.1ES will all updates applied:

losetup-2.11g-6
mount-2.11g-6
kernel-smp-2.4.9-e.49

We find that after mounting filesystems loopback, and then unmounting, the loop
device is not being freed. This causes us to eventually run out of loop devices
which means the machine must be rebooted.

Output of lsof:

[root@cslx1013 root]# for I in /dev/loop* ; do losetup $I ; done
/dev/loop0: [0809]:18 (RedHat_ES2.1u4-disc1.iso) offset 0, no encryption
/dev/loop1: [0809]:19 (RedHat_ES2.1u4-disc2.iso) offset 0, no encryption
loop: can\'t open device /dev/loop10: No such device
loop: can\'t open device /dev/loop11: No such device
loop: can\'t open device /dev/loop12: No such device
loop: can\'t open device /dev/loop13: No such device
loop: can\'t open device /dev/loop14: No such device
loop: can\'t open device /dev/loop15: No such device
/dev/loop2: [0809]:22 (RedHat_ES2.1u4-disc3.iso) offset 0, no encryption
/dev/loop3: [0809]:22 (RedHat_ES2.1u4-disc3.iso) offset 0, no encryption
/dev/loop4: [0809]:17 (RedHat_ES2.1u4-dvd.iso) offset 0, no encryption
/dev/loop5: [0809]:18 (../RedHat_ES2.1u4-disc1.iso) offset 0, no encryption
/dev/loop6: [0809]:19 (../RedHat_ES2.1u4-disc2.iso) offset 0, no encryption
/dev/loop7: [0809]:22 (../RedHat_ES2.1u4-disc3.iso) offset 0, no encryption
loop: can\'t open device /dev/loop8: No such device
loop: can\'t open device /dev/loop9: No such device

Trying to free these devices with losetup -d results in:

ioctl: LOOP_CLR_FD: Device or resource busy

 Further investigation shows that the open file handles are being kept open by
nautilus:

lsof | grep loop:

nautilus   8037    root   15r   BLK        7,0              66789 /dev/loop0
nautilus   8037    root   16r   BLK        7,1              66790 /dev/loop1
nautilus   8037    root   17r   BLK        7,2              66797 /dev/loop2
nautilus   8037    root   21r   BLK        7,3              66798 /dev/loop3
nautilus   8037    root   22r   BLK        7,4              66799 /dev/loop4
nautilus   8037    root   23r   BLK        7,4              66799 /dev/loop4
nautilus   8037    root   24r   BLK        7,5              66800 /dev/loop5
nautilus   8037    root   25r   BLK        7,6              66801 /dev/loop6
nautilus   8037    root   26r   BLK        7,7              66802 /dev/loop7
nautilus   8056    root   15r   BLK        7,0              66789 /dev/loop0
nautilus   8056    root   16r   BLK        7,1              66790 /dev/loop1
nautilus   8056    root   17r   BLK        7,2              66797 /dev/loop2
nautilus   8056    root   21r   BLK        7,3              66798 /dev/loop3
nautilus   8056    root   22r   BLK        7,4              66799 /dev/loop4
nautilus   8056    root   23r   BLK        7,4              66799 /dev/loop4
nautilus   8056    root   24r   BLK        7,5              66800 /dev/loop5
nautilus   8056    root   25r   BLK        7,6              66801 /dev/loop6
nautilus   8056    root   26r   BLK        7,7              66802 /dev/loop7
nautilus   8057    root   15r   BLK        7,0              66789 /dev/loop0

etc.

Restarting nautilus frees the file handles and then allows us to use losetup -d
to free the loop devices.
Comment 8 Alexander Larsson 2004-12-08 10:19:37 EST
This isn't a problem in RHEL4, and i'm pretty sure it doesn't happens in RHEL3
either (it has some code to ignore loopback mounts). Its unlikely we'll spend
any time on fixing this for AS 2.1 at this time, since this is the very old
gnome 1.4 desktop, so i'm gonna just close this as CURRENTRELEASE.

Note You need to log in before you can comment on or make changes to this bug.