Bug 482949 - 05-netfs unmounts loopback devices too
05-netfs unmounts loopback devices too
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
16
i686 Linux
low Severity high
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On:
Blocks: 516998 F11Target 553674
  Show dependency treegraph
 
Reported: 2009-01-28 17:42 EST by Adalbert Prokop
Modified: 2014-03-16 23:17 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 553674 (view as bug list)
Environment:
Last Closed: 2013-02-13 21:43:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Test script which creates a small loopback file in /tmp (431 bytes, text/plain)
2009-01-28 17:42 EST, Adalbert Prokop
no flags Details
Protoype code for fixing this bug (7.45 KB, patch)
2011-12-01 03:50 EST, Masatake YAMATO
no flags Details | Diff

  None (edit)
Description Adalbert Prokop 2009-01-28 17:42:45 EST
Created attachment 330297 [details]
Test script which creates a small loopback file in /tmp

Description of problem:
If you create a loopback mount and then change the WLAN using nm-applet and NetworkManager the mount and the loopback device association is no longer present.

Version-Release number of selected component (if applicable):
NetworkManager-0.7.0-1.git20090102.fc10.i386
kernel-2.6.27.12-170.2.5.fc10.i686

Steps to Reproduce:
1. Create a loopback mount
2. Change WLANs in nm-applet (or create a new one)
3. Type "mount" and watch the output - the loopback mount should be gone by now
  
I've created a little script to demonstrate this problem. It creates a small loopback in /tmp. I've no clue whatsoever why this happens. There are no suspicious log entries in /var/log/messages.
Comment 1 Dan Williams 2009-02-05 06:25:27 EST
This script and the loopback mount appear to work fine on F9 at least.  Is your system hostname set manually, or is it allowed to change based on the network?

Can you move /etc/NetworkManager/dispatcher.d/00-netreport and /etc/NetworkManager/dispatcher.d/05-netfs out of that directory and try this again?
Comment 2 Adalbert Prokop 2009-02-05 17:41:29 EST
My system hostname is set manually.
I've tried again and the problem is in 05-netfs. It calls "netfs stop" on interface shutdown. The netfs service calls "__umount_loopback_loop" from /etc/init.d/functions and it does what it has been programmed for: umounts all loopback devices. :-/

My question here: why are all loopback device beeing umounted when network filesystems are stopped?
Comment 3 Dan Williams 2009-02-05 18:36:27 EST
Any thoughts on this one Bill?
Comment 4 Bill Nottingham 2009-02-06 11:30:49 EST
Loopback mounts should only be unmounted if they're on a network filesystem (although it may not be implemented that way). It's a bug that they're getting unmounted here.
Comment 5 Bill Nottingham 2009-02-06 11:32:39 EST
It's not implemented that way right now, because pulling the backing device for a loopback mount and correlating it to a filesystem was messy. I'll see if it can be done better now.
Comment 6 Tomeu Vizoso 2009-03-22 15:00:05 EDT
This is causing Sugar to crash on a livecd setup because it has files open in $HOME and as $HOME gets mounted as a loopback device and init.d/functions calls fuser -k, there's a kill spree.

We're going to patch in our kickstart NM to not call netfs stop when the user disconnects from an AP, but I guess a proper fix should be found.
Comment 7 Simon Schampijer 2009-03-23 19:19:05 EDT
This is quite serious - and I guess Fedora will face it when live media will be available. Maybe it should be added to the F11Beta tracker?
Comment 8 Bill Nottingham 2009-03-24 12:13:57 EDT
What version of the Sugar livecd is this? This has been this way in NM/initscripts for nearly a year without bug reports except for this one.
Comment 9 Tomeu Vizoso 2009-03-24 12:21:20 EDT
(In reply to comment #8)
> What version of the Sugar livecd is this? This has been this way in
> NM/initscripts for nearly a year without bug reports except for this one.  

You should be able to reproduce this issue here:

http://download.sugarlabs.org/soas/snapshots/2/Soas2-200903211320.iso
Comment 10 Bug Zapper 2009-11-18 04:47:16 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 14 Bug Zapper 2010-11-04 07:32:13 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 15 Adalbert Prokop 2010-11-30 16:22:27 EST
Problem still exists in Fedora 14
Comment 16 Masatake YAMATO 2011-12-01 03:50:52 EST
Created attachment 538991 [details]
Protoype code for fixing this bug

See https://bugzilla.redhat.com/show_bug.cgi?id=482949.
netfs did umount all file systems mounted via /dev/loop*.
It was good if the backingstore for /dev/loopX was on nfs, cifs or
ncp.  However, it was not good if it was on local filesystem.
Consider iso image and/or squashfs image are at local file system 
and are mounted on somewhere via /dev/loop*.

With this patch netfs does umount only file systems which 
backingstores are at netfs. This patch tracks which file
system is used for a given backingstore recursively.

Here is the output of my test. See squashfs image mounted at
/tmp/X. The image is under /mnt where which a nfs is mounted.
So /tmp/X should be umount'ed when netfs is stopped. In other
hand /srv/sources is not umount'ed through it uses /dev/loop0
because its backingstore is under a file system mounted at
/var/lib/libvirt/images, a local block device.

    [root@localhost ~]# mount
    /dev/sda2 on / type ext4 (rw)
    proc on /proc type proc (rw)
    sysfs on /sys type sysfs (rw)
    devpts on /dev/pts type devpts (rw,gid=5,mode=620)
    tmpfs on /dev/shm type tmpfs (rw)
    /dev/sda1 on /boot type ext3 (rw)
    /dev/sda6 on /var/lib/libvirt/images type ext4 (rw)
    /var/lib/libvirt/images/dists-rhel4,rhel5,rhel6+optional-20110804.gzip.sqfs on /srv/sources type squashfs (ro,loop=/dev/loop0)
    none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
    sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
    sources:/srv/sources on /mnt type nfs (rw,addr=10.64.200.73)
    /mnt/attic/caskets/sqfs/dists-rhel4,rhel5,rhel6-20110706.sqfs on /tmp/X type squashfs (ro,loop=/dev/loop1)

    [root@localhost ~]# /etc/init.d/netfs stop
    Unmounting loopback filesystems:  [  OK  ]
    Unmounting NFS filesystems:  [  OK  ]

    [root@localhost ~]# mount
    /dev/sda2 on / type ext4 (rw)
    proc on /proc type proc (rw)
    sysfs on /sys type sysfs (rw)
    devpts on /dev/pts type devpts (rw,gid=5,mode=620)
    tmpfs on /dev/shm type tmpfs (rw)
    /dev/sda1 on /boot type ext3 (rw)
    /dev/sda6 on /var/lib/libvirt/images type ext4 (rw)
    /var/lib/libvirt/images/dists-rhel4,rhel5,rhel6+optional-20110804.gzip.sqfs on /srv/sources type squashfs (ro,loop=/dev/loop0)
    none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
    sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
Comment 17 Bill Nottingham 2011-12-01 16:39:16 EST
This patch relies heavily on deprecated /etc/mtab, so isn't suitable for now.
Comment 18 Masatake YAMATO 2011-12-04 22:26:29 EST
(In reply to comment #17)
> This patch relies heavily on deprecated /etc/mtab, so isn't suitable for now.

What kind of replacement can I use instead of /etc/mtab?
I'd like to submit a revised version of the patch.
Comment 19 Masatake YAMATO 2011-12-05 05:01:11 EST
(In reply to comment #17)
> This patch relies heavily on deprecated /etc/mtab, so isn't suitable for now.

I'm using mtab in two places.


1. In __on_netdevmtab()
   The code is copied from init.d/netfs.
   The original code is used for initializing NETDEVMTAB:

	    NETDEVMTAB=$(LC_ALL=C awk '$4 ~ /_netdev/ && $2 != "/" { print $2 }' /etc/mtab)

   For avoiding mtab the orignal code must be fixed.

2. In __backingstore_for_loopback()
   To get the path for the backingstore, /etc/mtab is referred.
   I used /etc/mtab because I cannot find the way to know the path 
   other than /etc/mtab. losetup, which uses ioctl, returns only incomplete 
   path because the buffer size limitation is in kernel. See /usr/include/linux/loop.h:

   #define LO_NAME_SIZE	64

   As far as I know there is no other interface provided by kernel.
   To avoid using /etc/mtab, I have to add newer interface to get the
   path to kernel.
Comment 20 Bill Nottingham 2011-12-05 15:50:13 EST
(In reply to comment #19)
> (In reply to comment #17)
> > This patch relies heavily on deprecated /etc/mtab, so isn't suitable for now.
> 
> I'm using mtab in two places.
> 
> 
> 1. In __on_netdevmtab()
>    The code is copied from init.d/netfs.
>    The original code is used for initializing NETDEVMTAB:
> 
>      NETDEVMTAB=$(LC_ALL=C awk '$4 ~ /_netdev/ && $2 != "/" { print $2 }'
> /etc/mtab)
> 
>    For avoiding mtab the orignal code must be fixed.

Right, working on that in a different bug.

The problem is that on newer releases, /etc/mtab is symlinked to /proc/mounts, which does not export the same set of information...

> 2. In __backingstore_for_loopback()
>    To get the path for the backingstore, /etc/mtab is referred.
>    I used /etc/mtab because I cannot find the way to know the path 
>    other than /etc/mtab. losetup, which uses ioctl, returns only incomplete 
>    path because the buffer size limitation is in kernel.

... such as this.
Comment 21 Roberto Ragusa 2011-12-31 11:37:55 EST
(In reply to comment #2)
> My system hostname is set manually.
> I've tried again and the problem is in 05-netfs. It calls "netfs stop" on
> interface shutdown. The netfs service calls "__umount_loopback_loop" from
> /etc/init.d/functions and it does what it has been programmed for: umounts all
> loopback devices. :-/
> 
> My question here: why are all loopback device beeing umounted when network
> filesystems are stopped?

I've just discovered minutes ago that this one is the bug which has been hitting me for months and made me spend hours and hours to track down.

The code is assuming that all loop filesystems are network based?
And killing everything using them??
And doing that automatically when the wireless signal drops???
And this is still unfixed after 3 years????

I have no words.

In my case, I have a loopback with squashfs, and then a unionfs to wrap the squashfs and make it writeable. I only start NetworkManager service when going wireless and the first loss of signal triggers NetworkManager, 05-nefs, netfs stop, __umount_loopback_loop, fuser, .... which kills the unionfs process.

My hypothesis was that unionfs was killed because it was stupidly matched by nfs grep rules. I would have never thought that *loopback* was forced to be unmounted by killing everyone.

Just done "chkconfig netfs off" and the problem is hidden for me. Sigh.

BTW, thanks to whoever introduced this bug, I've just learned how to use auditctl to discover who was ****ing killing my unionfs process. :-)
Comment 22 Tomeu Vizoso 2011-12-31 18:46:36 EST
(In reply to comment #21)
> (In reply to comment #2)
> > My system hostname is set manually.
> > I've tried again and the problem is in 05-netfs. It calls "netfs stop" on
> > interface shutdown. The netfs service calls "__umount_loopback_loop" from
> > /etc/init.d/functions and it does what it has been programmed for: umounts all
> > loopback devices. :-/
> > 
> > My question here: why are all loopback device beeing umounted when network
> > filesystems are stopped?
> 
> I've just discovered minutes ago that this one is the bug which has been
> hitting me for months and made me spend hours and hours to track down.
> 
> The code is assuming that all loop filesystems are network based?
> And killing everything using them??
> And doing that automatically when the wireless signal drops???
> And this is still unfixed after 3 years????
> 
> I have no words.

I spent a couple of days debugging it a few years ago. I say spent instead of wasted because I learnt to use systemtap to find out what was going on :)
Comment 23 Bryan Raney 2012-07-15 13:31:13 EDT
FYI, I am seeing this issue in Fedora 16.

Specifically, the Fedora Scientific Spin, based on Fedora 16.  I made the Live CD ISO into a Live USB with a writeable image file, mounted via /dev/loop*, used for /home.

Whenever a network connection is stopped (manually or not), /home is unmounted, causing all of the processes for "liveuser" to stop and the user to be instantly logged out.  (And since there is no /home anymore, liveuser cannot log back in.)

I don't understand why the unmount is successful when the filesystem is still in use, but that's probably a different issue.

Since I am not using network-based filesystems, I commented out the call to "__umount_loopback_loop" in /etc/rc.d/init.d/netfs, and this seems to have stopped the problem.
Comment 24 Jakub Dorňák 2012-07-16 07:34:51 EDT
I use loop device with vfat to share some files between different users on F16 and this happens to me every time the connection is stopped.

I see the message in /var/log/messages:
Jul 16 12:41:54 localhost dbus-daemon[1181]: Unmounting loopback filesystems:  [  OK  ]

How can I help to solve this? It is already more than three years...
Comment 25 Fedora End Of Life 2012-08-16 18:09:12 EDT
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 26 Karel Volný 2012-08-17 07:01:36 EDT
reopening and setting the version to F16 as per comment #23 and comment #24

if anyone is able to reproduce the problem with newer version, please update this appropriately
Comment 27 Bill Nottingham 2012-08-17 10:11:06 EDT
Note that netfs (and the associated NM dispatcher script) has been removed in F-18.
Comment 28 Emilio Scalise 2012-11-21 03:15:01 EST
I have the same problem on F17.
In particular the loop device is an image mounted by realcrypt.

How I can remove completely those scripts since I don't use them?



Nov 21 09:09:02 dellfear dbus-daemon[788]: Unmounting loopback filesystems (retry): [  OK  ]
Nov 21 09:09:02 dellfear dbus-daemon[788]: Detaching loopback device /dev/loop0:  losetup: /d
ev/loop0: detach failed: Device or resource busy
Comment 29 Fedora End Of Life 2013-01-16 20:19:09 EST
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 30 Fedora End Of Life 2013-02-13 21:43:19 EST
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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