| Summary: | PrivateTmp works incorrectly with `mount --make-rprivate /` | ||
|---|---|---|---|
| Product: | systemd | Reporter: | Stanislav <s.seletskiy> |
| Component: | general | Assignee: | systemd-bugs |
| Status: | RESOLVED NOTABUG | QA Contact: | systemd-bugs |
| Severity: | normal | ||
| Priority: | medium | CC: | s.seletskiy |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
# pacman -Qi systemd | grep Version Version : 208-1 # uname -a Linux *** 3.11.6-1-ARCH #1 SMP PREEMPT Fri Oct 18 23:22:36 CEST 2013 x86_64 GNU/Linux Well you disconnected the mount/umount propagation by marking the root dir private. So this is really what you should be expecting. Well, I should clarify, that without `PrivateTmp` option in service file sequence that contains `mount --make-rprivate /` works perfectly. So, somehow issue is not in making `/` private, but in `PrivateTmp` itself. You can reproduce what I'm talking about by stopping ntpd, ripping out `PrivateTmp` option from `ntpd.service` file, then mounting `/mnt`, starting `ntpd`, umounting `/mnt`. PrivateTmp= relies on mount propagation from the main namespace root dir. You turn this off, so PrivateTmp breaks. Either stop using PrivateTmp= or stop remounting the root dir private.. Sorry for bothering you, but can you explain, why is `PrivateTmp` behaves in that way? Why private `/tmp` directory affects on umount `/mnt` or any other directory under the `/`? I cannot parse your question, sorry. PrivateTmp= simply mounts a private /tmp for the service. The service should still see all other mounts coming and going though, which means the original mount heirachy needs to be shared, not private. If it was private, then the service would pin the file systems of the main hhierarchy forever, and users on the host can never properly umount any file system anymore. And that's simply not an option. However, `mount --make-rprivate /` is needed to get LXC containers to work. I mean that if service is not using `PrivateTmp` option, then any unmounts are propagated to the processes running inside service. Even if `mount --make-rprivate /` was issued before. So, problem arises ONLY if PrivateTmp and make-rprivate using together. Please, take a careful look on scenario I attached at first comment. Unmounts are propagated: # mount --make-rprivate / # mount blahblah /mnt # systemctl start ntpd (without PrivateTmp option in ntpd.service) # umount /mnt Unmounts are NOT propagated and unmounting /mnt CAUSES A PROBLEM: # mount --make-rprivate / # mount blahblah /mnt # systemctl start ntpd (WITH PrivateTmp option in ntpd.service, which is default) # umount /mnt Hope it is clear enough... (In reply to comment #7) > However, `mount --make-rprivate /` is needed to get LXC containers to work. I don't think that is true. I have no experience with LXC, but libvirt-lxc and systemd-nspawn have no issue with this at all. If LXC chokes on this it should really be fixed. LXC needs to do the same as nspawn and libvirt-lxc and do the equivalent of "mount --make-rslave /" *after* creating the container's fs namespace, from inside of it, in order to stop propagation of mounts from the container into the host but not vice versa. > I mean that if service is not using `PrivateTmp` option, then any unmounts > are propagated to the processes running inside service. Even if `mount > --make-rprivate /` was issued before. > > So, problem arises ONLY if PrivateTmp and make-rprivate using together. Yes. That's correct. So don't use make-rprivate on root. it's incompatible with privatetmp. > Please, take a careful look on scenario I attached at first comment. > > Unmounts are propagated: > # mount --make-rprivate / > # mount blahblah /mnt > # systemctl start ntpd (without PrivateTmp option in ntpd.service) > # umount /mnt > > Unmounts are NOT propagated and unmounting /mnt CAUSES A PROBLEM: > # mount --make-rprivate / > # mount blahblah /mnt > # systemctl start ntpd (WITH PrivateTmp option in ntpd.service, which is > default) > # umount /mnt > > Hope it is clear enough... Yeah, again, we don't support this. Either stop using PrivateTmp= or stop using make-rprivate on root. We don't support both in combination. Sorry. Thank you for clarifying that one! I should deal with LXC to stop rprivating /... |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
# dd if=/dev/zero of=/tmp/test-drive bs=1M count=100 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 0.0437981 s, 2.4 GB/s # mkfs.ext4 /tmp/test-drive mke2fs 1.42.8 (20-Jun-2013) /tmp/test-drive is not a block special device. Proceed anyway? (y,n) y Discarding device blocks: done Filesystem label= OS type: Linux ... # systemctl stop ntpd # mount /tmp/test-drive /mnt # systemctl start ntpd # umount /mnt # grep loop /proc/*/mounts | wc -l 0 # systemctl stop ntpd # mount --make-rprivate / # mount /tmp/test-drive /mnt # systemctl start ntpd # umount /mnt # grep loop /proc/*/mounts | wc -l 1 # grep loop /proc/*/mounts /proc/1411/mounts:/dev/loop0 /mnt ext4 rw,relatime,data=ordered 0 0 # pgrep -af ntpd 1411 /usr/bin/ntpd -g -u ntp:ntp # systemctl show ntpd | grep Fragme FragmentPath=/usr/lib/systemd/system/ntpd.service # grep Priva /usr/lib/systemd/system/ntpd.service PrivateTmp=true As you can see, umounting wouldn't work on unit that was started with PrivateTmp. This bug is very annoying while using ZFS On Linux, because it stops umounted dataset to be destroyed ("dataset is busy").