On Mon, 30.06.14 12:23, Colin Walters (walt...@verbum.org) wrote: > Hi, we were trying to update systemd to git master in gnome-continuous, > and hit an issue with mount points that are symlinks. > > It's pretty easy to reproduce: > > mkdir /mnt/a > ln -s a /mnt/b > cat > /etc/systemd/system/mnt-b.mount << EOF > [Mount] > What=tmpfs > Where=/mnt/b > Type=tmpfs > Options=mode=1777,strictatime > EOF > systemctl daemon-reload > systemctl start mnt-b.mount > > # Notice that we can see this mount via *both* units: > systemctl status mnt-a.mount > systemctl status mnt-b.mount > > # Now let's do an unrelated mount: > > mkdir /mnt/unrelated > mount --bind /mnt/unrelated /mnt/unrelated > > systemctl status mnt-a.mount > systemctl status mnt-b.mount > # Notice mnt-b died > > This happens because on any mountpoint change, we mark all mounts as > dead, and only reload the ones we see. But the kernel resolved the b -> > a symlink at mount time, so it doesn't exist from the kernel's > perspective. > > In gnome-continuous this breaks the /tmp -> /sysroot/tmp link; which I > could work around in a different way perhaps, but it would be nice if > systemd had better semantics for mount points that are symlinks.
Why would you create such a symlink? This sounds wrong. /tmp should generally be a tmpfs these days, why would you link that? BTW, I have now prepped a man page that codifies the assumptions and suggestions systemd makes on the file system hierarchy: http://www.freedesktop.org/software/systemd/man/file-hierarchy.html > What would the right thing here be? Should e.g. systemd follow the > links and create two units from mount points that contain symlinks, > explicitly having the source reflect destination? I am pretty sure we should simply prohibit mounts on existing symlinks. Sounds unnecessary and pretty dangerous to me. Not entirely sure though how we can effectively prohibit this, given that there is no lmount(), i.e. a mount() that refuses following mount points. We could implement this in a racy way by stat()ing first, which might be good enough (after all this requires priv), but of course not pretty... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel