[systemd-devel] Is there a reason to forcefully create /etc/mtab?
Hi, I have a read-only / filesystem and /etc/mtab points to /proc/self/mounts as it should. So, in systemd-215 tmpfile.d fails to create a symbolic link /etc/mtab because /usr/lib/tmpfiles.d/etc.conf contains is a line L+ /etc/mtab - - - - ../proc/self/mounts. Is this intentional? Besides failing on ro /, it is also confusing because /etc/mtab can be supplied by a package (in archlinux, the 'filesystem' package), so why tmpfiles instead of including this symlink with systemd? The same question applies to the entire etc.conf: why does tmpfiles touch /etc at all, especially if /etc is already properly set up? Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpLVP4W5dKM6.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a reason to forcefully create /etc/mtab?
On Sunday 06 July 2014 at 13:01:22, Leonid Isaev wrote: Hi, I have a read-only / filesystem and /etc/mtab points to /proc/self/mounts as it should. So, in systemd-215 tmpfile.d fails to create a symbolic link /etc/mtab because /usr/lib/tmpfiles.d/etc.conf contains is a line L+ /etc/mtab - - - - ../proc/self/mounts. Is this intentional? Besides failing on ro /, it is also confusing because /etc/mtab can be supplied by a package (in archlinux, the 'filesystem' package), so why tmpfiles instead of including this symlink with systemd? The same question applies to the entire etc.conf: why does tmpfiles touch /etc at all, especially if /etc is already properly set up? Thanks, L+ (as well as any other + directives) only force-overwrite files if this is needed, e. g. if a symlink points to the wrong desination. -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a reason to forcefully create /etc/mtab?
On Sun, Jul 6, 2014 at 1:08 PM, Ivan Shapovalov intelfx...@gmail.com wrote: On Sunday 06 July 2014 at 13:01:22, Leonid Isaev wrote: Hi, I have a read-only / filesystem and /etc/mtab points to /proc/self/mounts as it should. So, in systemd-215 tmpfile.d fails to create a symbolic link /etc/mtab because /usr/lib/tmpfiles.d/etc.conf contains is a line L+ /etc/mtab - - - - ../proc/self/mounts. Is this intentional? Besides failing on ro /, it is also confusing because /etc/mtab can be supplied by a package (in archlinux, the 'filesystem' package), so why tmpfiles instead of including this symlink with systemd? The same question applies to the entire etc.conf: why does tmpfiles touch /etc at all, especially if /etc is already properly set up? Thanks, L+ (as well as any other + directives) only force-overwrite files if this is needed, e. g. if a symlink points to the wrong desination. Right. I think the path matching is a little naive; Using a simple string comparison, /proc/self/mounts != ../proc/self/mounts even though both paths refer to the same object. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a reason to forcefully create /etc/mtab?
On Sunday 06 July 2014 at 13:13:55, Mike Gilbert wrote: On Sun, Jul 6, 2014 at 1:08 PM, Ivan Shapovalov intelfx...@gmail.com wrote: On Sunday 06 July 2014 at 13:01:22, Leonid Isaev wrote: Hi, I have a read-only / filesystem and /etc/mtab points to /proc/self/mounts as it should. So, in systemd-215 tmpfile.d fails to create a symbolic link /etc/mtab because /usr/lib/tmpfiles.d/etc.conf contains is a line L+ /etc/mtab - - - - ../proc/self/mounts. Is this intentional? Besides failing on ro /, it is also confusing because /etc/mtab can be supplied by a package (in archlinux, the 'filesystem' package), so why tmpfiles instead of including this symlink with systemd? The same question applies to the entire etc.conf: why does tmpfiles touch /etc at all, especially if /etc is already properly set up? Thanks, L+ (as well as any other + directives) only force-overwrite files if this is needed, e. g. if a symlink points to the wrong desination. Right. I think the path matching is a little naive; Using a simple string comparison, /proc/self/mounts != ../proc/self/mounts even though both paths refer to the same object. No, they aren't referring to the same object. This makes a difference when you mount a foreign system image for maintainance. -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a reason to forcefully create /etc/mtab?
On Sun, Jul 06, 2014 at 09:15:28PM +0400, Ivan Shapovalov wrote: On Sunday 06 July 2014 at 13:13:55, Mike Gilbert wrote: On Sun, Jul 6, 2014 at 1:08 PM, Ivan Shapovalov intelfx...@gmail.com wrote: On Sunday 06 July 2014 at 13:01:22, Leonid Isaev wrote: Hi, I have a read-only / filesystem and /etc/mtab points to /proc/self/mounts as it should. So, in systemd-215 tmpfile.d fails to create a symbolic link /etc/mtab because /usr/lib/tmpfiles.d/etc.conf contains is a line L+ /etc/mtab - - - - ../proc/self/mounts. Is this intentional? Besides failing on ro /, it is also confusing because /etc/mtab can be supplied by a package (in archlinux, the 'filesystem' package), so why tmpfiles instead of including this symlink with systemd? The same question applies to the entire etc.conf: why does tmpfiles touch /etc at all, especially if /etc is already properly set up? Thanks, L+ (as well as any other + directives) only force-overwrite files if this is needed, e. g. if a symlink points to the wrong desination. Right. I think the path matching is a little naive; Using a simple string comparison, /proc/self/mounts != ../proc/self/mounts even though both paths refer to the same object. No, they aren't referring to the same object. This makes a difference when you mount a foreign system image for maintainance. Cool :( So... the solution would be for distro packages to ship mtab as a symlink to ../proc instead of /proc? Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpzLf2uY3vGl.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a reason to forcefully create /etc/mtab?
On Sun, Jul 06, 2014 at 01:44:05PM -0400, Leonid Isaev wrote: On Sun, Jul 06, 2014 at 09:15:28PM +0400, Ivan Shapovalov wrote: On Sunday 06 July 2014 at 13:13:55, Mike Gilbert wrote: On Sun, Jul 6, 2014 at 1:08 PM, Ivan Shapovalov intelfx...@gmail.com wrote: On Sunday 06 July 2014 at 13:01:22, Leonid Isaev wrote: Hi, I have a read-only / filesystem and /etc/mtab points to /proc/self/mounts as it should. So, in systemd-215 tmpfile.d fails to create a symbolic link /etc/mtab because /usr/lib/tmpfiles.d/etc.conf contains is a line L+ /etc/mtab - - - - ../proc/self/mounts. Is this intentional? Besides failing on ro /, it is also confusing because /etc/mtab can be supplied by a package (in archlinux, the 'filesystem' package), so why tmpfiles instead of including this symlink with systemd? The same question applies to the entire etc.conf: why does tmpfiles touch /etc at all, especially if /etc is already properly set up? Thanks, L+ (as well as any other + directives) only force-overwrite files if this is needed, e. g. if a symlink points to the wrong desination. Right. I think the path matching is a little naive; Using a simple string comparison, /proc/self/mounts != ../proc/self/mounts even though both paths refer to the same object. No, they aren't referring to the same object. This makes a difference when you mount a foreign system image for maintainance. Cool :( So... the solution would be for distro packages to ship mtab as a symlink to ../proc instead of /proc? No, the latter is fine, or even better. The solution is for systmed-tmpfiles to stop complaining when the fs is readonly. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a reason to forcefully create /etc/mtab?
Hi, On Sun, Jul 06, 2014 at 08:13:56PM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Sun, Jul 06, 2014 at 01:44:05PM -0400, Leonid Isaev wrote: So... the solution would be for distro packages to ship mtab as a symlink to ../proc instead of /proc? No, the latter is fine, or even better. The solution is for systmed-tmpfiles to stop complaining when the fs is readonly. Well, I actually would like it to complain (that's why I keep / read-only). I'd rather change L+ to L... Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpMEK60D0vTU.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a reason to forcefully create /etc/mtab?
On Sun, 06.07.14 13:01, Leonid Isaev (lis...@umail.iu.edu) wrote: Hi, I have a read-only / filesystem and /etc/mtab points to /proc/self/mounts as it should. So, in systemd-215 tmpfile.d fails to create a symbolic link /etc/mtab because /usr/lib/tmpfiles.d/etc.conf contains is a line L+ /etc/mtab - - - - ../proc/self/mounts. Is this intentional? Besides failing on ro /, it is also confusing because /etc/mtab can be supplied by a package (in archlinux, the 'filesystem' package), so why tmpfiles instead of including this symlink with systemd? The same question applies to the entire etc.conf: why does tmpfiles touch /etc at all, especially if /etc is already properly set up? tmpfiles won't do anything with the symlink if it already exists and already points to the right place. It will only create the symlink (and possible delete the existing file) if it is missing or not of the righ type or not pointing to the right place. The reason I added this was current behaviour of mount(8), which created /etc/mtab as file if it was missing, and that even with -n. (which got fixed in git upstream afaik, but not yet released?). This is useful when /etc is booted up empty. Anyway, the tmpfiles stuff we do is intended to be a NOP if /etc is already set up properly. Of course, we could be a pinch smarter here, and actually understand relative symlinks when comparing if the existing symlink aready points to the right place... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a reason to forcefully create /etc/mtab?
On Sun, 06.07.14 13:44, Leonid Isaev (lis...@umail.iu.edu) wrote: I think the path matching is a little naive; Using a simple string comparison, /proc/self/mounts != ../proc/self/mounts even though both paths refer to the same object. No, they aren't referring to the same object. This makes a difference when you mount a foreign system image for maintainance. Cool :( So... the solution would be for distro packages to ship mtab as a symlink to ../proc instead of /proc? Well, it's slightly nicer to use relative symlinks for things like this, since this means that if you install an OS hierarchy into some subdirectory somewhere the symlinks will always point to files inside of the hierarchy, and not into the host's OS hierarchy, if you follow what I mean. I figure we should fix tmpfiles to understand that relative and absolute symlinks are both OK, even though it should probably create only relative symlinks. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a reason to forcefully create /etc/mtab?
On Sun, 06.07.14 20:13, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: I think the path matching is a little naive; Using a simple string comparison, /proc/self/mounts != ../proc/self/mounts even though both paths refer to the same object. No, they aren't referring to the same object. This makes a difference when you mount a foreign system image for maintainance. Cool :( So... the solution would be for distro packages to ship mtab as a symlink to ../proc instead of /proc? No, the latter is fine, or even better. The solution is for systmed-tmpfiles to stop complaining when the fs is readonly. I am pretty sure we should complain in that case: after all the mtab situation was bad enough that we included it in the taint flags since a long time (the ones printed with systemctl show -p Tainted). I'd really prefer if we would complain if something we are told to do cannot be done. However, I think we should try our best to figure out that what is already in place might already be completely in order, even if that means that we need to teach tmpfiles to understand when relative and absolute symlinks are equivalent. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
