Bug 844997 - bind mounted targets can not be removed after unmounting them
bind mounted targets can not be removed after unmounting them
Product: oVirt
Classification: Community
Component: ovirt-node (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Mike Burns
Depends On:
  Show dependency treegraph
Reported: 2012-08-01 08:33 EDT by Fabian Deutsch
Modified: 2016-04-27 00:27 EDT (History)
10 users (show)

See Also:
Fixed In Version: 2.6.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-02-13 08:38:07 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Fabian Deutsch 2012-08-01 08:33:05 EDT
Description of problem:
The targets of the bind mounts from /config can not be removed

Version-Release number of selected component (if applicable):
F17 based builds

How reproducible:

Steps to Reproduce:
1. Install Node 2.5.0-2
2. Login and configure network with dhcp
3. drop to shell
4. unpersist /etc/sysconfig/network-scripts/ifcfg-breth0
5. rm /etc/sysconfig/network-scripts/ifcfg-breth0

Actual results:
File can not be removed because of EBUSY

Expected results:
File can be removed (as /etc is a tmpfs, and not ro)

Additional info:
It seems that that ntpd.service is now using systemd's PrivateTmp feature, thus a private namespace is created for ntpd.service. When the service is stopped the previosuly bind mounted targets can be removed.
Comment 1 Fabian Deutsch 2012-08-01 09:02:15 EDT

I'm adding your because you were driving this effort in F17. Have you got an idea why this problem appears or do you need more informations?
Comment 2 Daniel Walsh 2012-08-01 15:34:10 EDT
If you run 

mount -rshared / 

Before mounting and starting ntpd does the problem go away?
Comment 3 Fabian Deutsch 2012-08-01 16:16:28 EDT
(In reply to comment #2)
> If you run 
> mount -rshared / 
> Before mounting and starting ntpd does the problem go away?

Yes, that solved it.

Could you explain the problem and the solution?
Comment 4 Daniel Walsh 2012-08-02 16:07:14 EDT
This says that All namespaces will share any mounts/unmounts that happen to the parent namespace on the / directory.  I believe this should be the default.  But as of right now it is not.
Comment 5 Mike Burns 2012-08-02 16:20:37 EDT
Hi Dan,

Is there an fstab option we can set to make that the default?  I can't find any documentation on how to set that in any way other than with the --make-rshared mount option.  

Comment 6 Daniel Walsh 2012-08-03 07:45:51 EDT
No, we have a bug report on this but it has been rejected.  You either need an init script/unit file or we need to convince systemd to do this automatically.
Comment 7 Fabian Deutsch 2012-08-03 08:04:51 EDT
I wonder why systemd is not mounting / appropriately if they offer the PrivateTmp feature. Or is our use case a corner case?
Comment 8 Mike Burns 2012-08-03 09:19:27 EDT
OK, we'll add this command to our early init script.
Comment 9 Lennart Poettering 2012-08-03 16:05:14 EDT
Hmm, so in the long run we really should have the namespace inheritance options a mount option like any other, so that people can list them in fstab.

However, I still believe that the default (which should apply when you have no fstab or no line for / in it) should be shared. Since the kernel default is private (and probably shouldnb't be changed) I think I'll just make systemd remount / shared unconditionally. That means that everybody who wants private mounts needs to either a) wait for the kernel to be fixed to accept the namespace inheritance options like any other options, b) write a little service on their own that does mount --make-private / to undo what systemd did.
Comment 10 Daniel Walsh 2012-08-06 10:42:52 EDT
I agree the default should be shared and anyone needing private, should take care of that on their own.
Comment 11 Lennart Poettering 2012-08-07 05:54:09 EDT
systemd in git will now mount the root file system "shared". This will soon enter Rawhide.
Comment 12 Mike Burns 2012-08-07 13:29:56 EDT
patch for ovirt-node until this gets into fedora:

Comment 13 Mike Burns 2013-02-13 08:38:07 EST
This bug has been fixed in the 2.6.0 release of ovirt-node, which is now available on both ovirt.org and in Fedora 18

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