Bug 844997 - bind mounted targets can not be removed after unmounting them
Summary: bind mounted targets can not be removed after unmounting them
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-node
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Mike Burns
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-08-01 12:33 UTC by Fabian Deutsch
Modified: 2016-04-27 04:27 UTC (History)
10 users (show)

Fixed In Version: 2.6.0
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-13 13:38:07 UTC
oVirt Team: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1251151 0 urgent CLOSED Can not login RHEV-H after automatic installation on physical machine: Authentication token manipulation error 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1262725 1 None None None 2021-01-20 06:05:38 UTC

Internal Links: 1251151 1262725

Description Fabian Deutsch 2012-08-01 12:33:05 UTC
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:
Always

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 13:02:15 UTC
Daniel,

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 19:34:10 UTC
If you run 

mount -rshared / 

Before mounting and starting ntpd does the problem go away?

Comment 3 Fabian Deutsch 2012-08-01 20:16:28 UTC
(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 20:07:14 UTC
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 20:20:37 UTC
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.  

thanks

Comment 6 Daniel Walsh 2012-08-03 11:45:51 UTC
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 12:04:51 UTC
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 13:19:27 UTC
OK, we'll add this command to our early init script.

Comment 9 Lennart Poettering 2012-08-03 20:05:14 UTC
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 14:42:52 UTC
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 09:54:09 UTC
systemd in git will now mount the root file system "shared". This will soon enter Rawhide.

Comment 12 Mike Burns 2012-08-07 17:29:56 UTC
patch for ovirt-node until this gets into fedora:

http://gerrit.ovirt.org/#/c/6936/

Comment 13 Mike Burns 2013-02-13 13:38:07 UTC
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.