Re: [systemd-devel] New mount restriction? -- from Systemd policy?
On Mon, Apr 8, 2013 at 3:45 PM, Linda Walsh s...@tlinx.org wrote: Is it something that systemd needed to have? I.e. if it is made private would systemd care? If not, why would it have been made shared? Maybe a default in mount for root changed? Having the default mount propagation be shared solves some situations where a configuration item (say, PrivateTmp=) requires spawning a service in a Linux kernel file system namespace. Other mounts that happen post-service start aren't visible to the service, despite being visible and functional to administrators. It's hard to debug, and it won't show any obvious warnings or errors in logs. I don't believe making root private breaks systemd itself. I think it just makes other administration potentially confusing. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] New mount restriction? -- from Systemd policy?
Here is the commit with some background: http://cgit.freedesktop.org/systemd/systemd/commit/?id=b3ac5f8cb98757416d8660023d6564a7c411f0a0 On Thu, Apr 11, 2013 at 11:42 PM, David Strauss da...@davidstrauss.net wrote: On Mon, Apr 8, 2013 at 3:45 PM, Linda Walsh s...@tlinx.org wrote: Is it something that systemd needed to have? I.e. if it is made private would systemd care? If not, why would it have been made shared? Maybe a default in mount for root changed? Having the default mount propagation be shared solves some situations where a configuration item (say, PrivateTmp=) requires spawning a service in a Linux kernel file system namespace. Other mounts that happen post-service start aren't visible to the service, despite being visible and functional to administrators. It's hard to debug, and it won't show any obvious warnings or errors in logs. I don't believe making root private breaks systemd itself. I think it just makes other administration potentially confusing. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] New mount restriction? -- from Systemd policy?
Andrey Borzenkov wrote: This seems to be yest another fallout of changed systemd policy - it now makes / shared mount. bor@opensuse:~ sudo mount --move /tmp/old /tmp/new mount: wrong fs type, bad option, bad superblock on /tmp/old, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so bor@opensuse:~ sudo mount --make-private / bor@opensuse:~ sudo mount --move /tmp/old /tmp/new bor@opensuse:~ cd Is that another systemd change, really? Aren't fs's mounted on initrd before systemd is invoked? Is it something that systemd needed to have? I.e. if it is made private would systemd care? If not, why would it have been made shared? Maybe a default in mount for root changed? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
