-
Notifications
You must be signed in to change notification settings - Fork 244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
init.d/root: add support for 'shared' fstab option on / #526
Conversation
This should fix the warning message for rootless podman/buildah: containers/buildah#3726
|
Yes, that's the main reason I want this :) (well, that and shared mounts can actually be useful for containers -- with volume mounted as shared it's possible to have an administration container that can issue mount commands for slave, less trusted containers) |
was there anything more to do here to allow it to be merged? looks pretty cut and dry to me |
For reference, I've been using something equivalent to this for a bit over a year now without any issue. I'll be more than happy to remove my kludge if/when this is merged :) |
Is that the problem? Strange mistake. |
I hope it will merged soon :) Now i use /var/lib/docker folder all of shared container mounts. This folder shared by default, if docker installed :D |
the mount(8) man page says it recognizes the various types in fstab (private, slave, shared, unbindable, rprivate, rslave, rshared, runbindable). we shouldn't treat "shared" as "rshared". if you want the man page also says that since util-linux 2.23, the fstab propagation flags are respected by mount. i'm guessing this doesn't work for |
The rationale for using rshared when shared is set on /, is that it is supposed to be inherited -- but since we're setting rootflags late (after other mount points have been made) then we need rshared to behave as if it had been shared from the start. (otherwise you end up with something weird where part of the tree is shared but it's not really clear to users what) Happy to update the PR to change that though, it's a detail really. As for |
Just tested the change in an Alpine 3.18 VM (amd64, system disk). Works fine:
|
@vapier If the PR was changed to use the I would love to see this fixed upstream for everyone! Thank you. |
Ah, I realized I forgot to reply to a point:
This doesn't just have no effect, mount -o doesn't seem to allow passing shared or other similar options:
re: fstab flag, as said before I still think it makes more sense as it is, but happy to do the updating if that's what you want. |
Perhaps there should be a shared and a rshared option? So people explicitly knows that rshared is recursive and shared is not. |
This was brought up before so I'll just quote my reply:
To rephrase myself, the shared setting will be inherited by future mounts, so depending on the timing of the "make root shared" you'll get something implementation specific with a simple It's an easy change so given the above, if someone still think that makes sense I'll be happy to update this PR to at least rename shared to rshared to make it more obvious that it's what we're doing; please re-ask if that's the case. |
Oh sorry, missed that. I actually don't care that much about the details, I just want it implemented. |
@navi-desu Could you possibly provide some feedback here as to how we can git this PR merged? |
i'm looking over shared mounts, since we run this at boot and remount doesn't seem to apply the shared status, --make-rshared would make sense, otherwise any mounts existing before the script is called would not have the propagation applied, so the question is, can a mount exist before the script is called? tho, both shared and rshared are mount options, wouldn't it make sense for us to match on both? also, we call |
yes, mounts like /dev are made by the kernel before this if no initrd, and if there is an initrd anything can happen. I don't think shared without r makes sense here precisely because we don't know the state the fs will be in here (need to check script dependencies with e.g. sysfs cgroup etc services that all happen at boot and have no reason to have a dependency on this), but if that helps merging I don't really care so happy to handle both, it's just more code that probably won't be used much
happy to assign it to a variable, yes; will update the patch next week |
got it, and i agree then, since anything can happen, it's more consistent to reapply it. btw by handling both i just mean |
ah, hadn't understood it that way -- this is probably fine/welcome, I've fixed it up along with the variable and a trivial rebase (can't really re-test until next week but this is probably fine; will repost next week after checking it still works as of master) |
nit: in anyway, we can merge this as soon as it's tested again. it seems fine to me but i don't know how to properly reproduce the scenario this fixes, i can test as well if there's any steps to reproduce |
I can confirm that this change does fix the issues linked. I tested on Alpine Linux 3.20. |
containers on linux might require filesystems to be mounted with different propagation than the kernel default of 'private': by setting 'shared' in fstab for / options, one can now make the fs hierarchy shared. Note we use 'rshared' to make other existing mounts shared as well because the setting is contagious and it seemed more logical to behave as if the setting was set on / immediately (and thus inherited by other mounts) This fixes OpenRC#525.
renamed. It's actually mount options so
|
thanks! |
Any idea when this will be in a tagged release? Doesn't look like it's in 0.54.2 afaict. |
containers on linux might require filesystems to be mounted with
different propagation than the kernel default of 'private':
by setting 'shared' in fstab for / options, one can now make the
fs hierarchy shared.
Note we use 'rshared' to make other existing mounts shared as well
because the setting is contagious and it seemed more logical to
behave as if the setting was set on / immediately (and thus inherited
by other mounts)
This fixes #525.