[systemd-devel] PrivateTmp and systemd-tmpfiles
Hello, Today I have read this bug https://bugzilla.redhat.com/show_bug.cgi?id=866693 and described systemd-tmpfiles behavior look pretty wrong to me, but I am not sure how to fix it. Some ideas cross my mind; moving systemd-namespace-* elsewhere, adding some option to exclude dirs in tmpfiles conf files, stop cleaning /tmp, hardcode some excludes to tmpfiles, but I don't like any of these solutions. Smaller reproducer: /usr/lib/tmpfiles.d/tmp.conf d /tmp 1777 root root 20s a.service [Unit] Description=unit %n [Service] Type=simple ExecStart=/root/test.sh StandardOutput=syslog PrivateTmp=yes /root/test.sh #!/bin/bash sleep 40 echo "hello world" > /tmp/xxx exit 0 and then run something like systemctl start a.service & watch 'systemd-tmpfiles --clean tmp.conf; ls -al /tmp; systemctl status a.service' Regards Lukas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PrivateTmp and systemd-tmpfiles
On Wed, 17.10.12 14:16, Lukáš Nykrýn (lnyk...@redhat.com) wrote: > Hello, > Today I have read this bug > https://bugzilla.redhat.com/show_bug.cgi?id=866693 and described > systemd-tmpfiles behavior look pretty wrong to me, but I am not sure how > to fix it. Some ideas cross my mind; moving systemd-namespace-* > elsewhere, adding some option to exclude dirs in tmpfiles conf files, > stop cleaning /tmp, hardcode some excludes to tmpfiles, but I don't like > any of these solutions. We already allow files to be excluded from clean up by setting the sticky bit on them. We can't do that for dirs however, since the sticky bit for dirs has a different meaning. One possible way to solve this issue otherwise might be by introducing an xattr for this. The one thing blocking this right now however is that tmpfs still can't handle xattrs properly. There were multiple attempts to get xattrs for tmpfs into the kernel, not sure what the latest state on this is. The best would probably be to exclude these dirs from clean-up via explicit tmpfiles lines. Unfortunately "x" is probably not going to do it here, since we actually want recursive clean-up inside the dir, just not of the dir... So maybe introduce a new type of "X" that excludes the dir itself from clean-up but does not exclude recursively? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PrivateTmp and systemd-tmpfiles
On Wed, Oct 17, 2012 at 6:10 PM, Lennart Poettering wrote: > On Wed, 17.10.12 14:16, Lukáš Nykrýn (lnyk...@redhat.com) wrote: > >> Hello, >> Today I have read this bug >> https://bugzilla.redhat.com/show_bug.cgi?id=866693 and described >> systemd-tmpfiles behavior look pretty wrong to me, but I am not sure how >> to fix it. Some ideas cross my mind; moving systemd-namespace-* >> elsewhere, adding some option to exclude dirs in tmpfiles conf files, >> stop cleaning /tmp, hardcode some excludes to tmpfiles, but I don't like >> any of these solutions. > > We already allow files to be excluded from clean up by setting the > sticky bit on them. We can't do that for dirs however, since the sticky > bit for dirs has a different meaning. One possible way to solve this > issue otherwise might be by introducing an xattr for this. The one thing > blocking this right now however is that tmpfs still can't handle xattrs > properly. There were multiple attempts to get xattrs for tmpfs into the > kernel, not sure what the latest state on this is. > > The best would probably be to exclude these dirs from clean-up via > explicit tmpfiles lines. Unfortunately "x" is probably not going to do > it here, since we actually want recursive clean-up inside the dir, just > not of the dir... So maybe introduce a new type of "X" that excludes the > dir itself from clean-up but does not exclude recursively? Pre-create and protect a /tmp/systemd-namespace/ subdir? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PrivateTmp and systemd-tmpfiles
2012/10/17 Lennart Poettering : > On Wed, 17.10.12 14:16, Lukáš Nykrýn (lnyk...@redhat.com) wrote: > >> Hello, >> Today I have read this bug >> https://bugzilla.redhat.com/show_bug.cgi?id=866693 and described >> systemd-tmpfiles behavior look pretty wrong to me, but I am not sure how >> to fix it. Some ideas cross my mind; moving systemd-namespace-* >> elsewhere, adding some option to exclude dirs in tmpfiles conf files, >> stop cleaning /tmp, hardcode some excludes to tmpfiles, but I don't like >> any of these solutions. > > We already allow files to be excluded from clean up by setting the > sticky bit on them. We can't do that for dirs however, since the sticky > bit for dirs has a different meaning. Maybe create a new (empty) file inside this dir (on creation of the namespace) and set the sticky bit on it. This way tmpfiles will never delete the dir because it is not empty. Also everything needed when the service is stopped is removing this file so tmpfiles can clean up next time it passes by. > One possible way to solve this > issue otherwise might be by introducing an xattr for this. The one thing > blocking this right now however is that tmpfs still can't handle xattrs > properly. There were multiple attempts to get xattrs for tmpfs into the > kernel, not sure what the latest state on this is. > > The best would probably be to exclude these dirs from clean-up via > explicit tmpfiles lines. Unfortunately "x" is probably not going to do > it here, since we actually want recursive clean-up inside the dir, just > not of the dir... So maybe introduce a new type of "X" that excludes the > dir itself from clean-up but does not exclude recursively? Simon Peeters ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PrivateTmp and systemd-tmpfiles
Kay Sievers píše v St 17. 10. 2012 v 18:28 +0200: > On Wed, Oct 17, 2012 at 6:10 PM, Lennart Poettering > wrote: > > On Wed, 17.10.12 14:16, Lukáš Nykrýn (lnyk...@redhat.com) wrote: > > > >> Hello, > >> Today I have read this bug > >> https://bugzilla.redhat.com/show_bug.cgi?id=866693 and described > >> systemd-tmpfiles behavior look pretty wrong to me, but I am not sure how > >> to fix it. Some ideas cross my mind; moving systemd-namespace-* > >> elsewhere, adding some option to exclude dirs in tmpfiles conf files, > >> stop cleaning /tmp, hardcode some excludes to tmpfiles, but I don't like > >> any of these solutions. > > > > We already allow files to be excluded from clean up by setting the > > sticky bit on them. We can't do that for dirs however, since the sticky > > bit for dirs has a different meaning. One possible way to solve this > > issue otherwise might be by introducing an xattr for this. The one thing > > blocking this right now however is that tmpfs still can't handle xattrs > > properly. There were multiple attempts to get xattrs for tmpfs into the > > kernel, not sure what the latest state on this is. > > > > The best would probably be to exclude these dirs from clean-up via > > explicit tmpfiles lines. Unfortunately "x" is probably not going to do > > it here, since we actually want recursive clean-up inside the dir, just > > not of the dir... So maybe introduce a new type of "X" that excludes the > > dir itself from clean-up but does not exclude recursively? > > Pre-create and protect a /tmp/systemd-namespace/ subdir? > > Kay What about saving private tmp and var/tmp paths to service struct when service is started and then systemd-tmpfiles can obtain all currently used paths and skip them (but not their content)? I don't think that simply skip /tmp/systemd-privat-XXX would be a good idea because these dirs would be never deleted even if the service is already dead. Lukas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PrivateTmp and systemd-tmpfiles
On Thu, 18.10.12 14:42, Lukáš Nykrýn (lnyk...@redhat.com) wrote: > > Kay Sievers píše v St 17. 10. 2012 v 18:28 +0200: > > On Wed, Oct 17, 2012 at 6:10 PM, Lennart Poettering > > wrote: > > > On Wed, 17.10.12 14:16, Lukáš Nykrýn (lnyk...@redhat.com) wrote: > > > > > >> Hello, > > >> Today I have read this bug > > >> https://bugzilla.redhat.com/show_bug.cgi?id=866693 and described > > >> systemd-tmpfiles behavior look pretty wrong to me, but I am not sure how > > >> to fix it. Some ideas cross my mind; moving systemd-namespace-* > > >> elsewhere, adding some option to exclude dirs in tmpfiles conf files, > > >> stop cleaning /tmp, hardcode some excludes to tmpfiles, but I don't like > > >> any of these solutions. > > > > > > We already allow files to be excluded from clean up by setting the > > > sticky bit on them. We can't do that for dirs however, since the sticky > > > bit for dirs has a different meaning. One possible way to solve this > > > issue otherwise might be by introducing an xattr for this. The one thing > > > blocking this right now however is that tmpfs still can't handle xattrs > > > properly. There were multiple attempts to get xattrs for tmpfs into the > > > kernel, not sure what the latest state on this is. > > > > > > The best would probably be to exclude these dirs from clean-up via > > > explicit tmpfiles lines. Unfortunately "x" is probably not going to do > > > it here, since we actually want recursive clean-up inside the dir, just > > > not of the dir... So maybe introduce a new type of "X" that excludes the > > > dir itself from clean-up but does not exclude recursively? > > > > Pre-create and protect a /tmp/systemd-namespace/ subdir? > > > > Kay > > What about saving private tmp and var/tmp paths to service struct when > service is started and then systemd-tmpfiles can obtain all currently > used paths and skip them (but not their content)? I'd like to keep this losely coupled, if possible, i.e. not require communication with PID 1 from tmpfiles, if we can. > I don't think that simply skip /tmp/systemd-privat-XXX would be a good > idea because these dirs would be never deleted even if the service is > already dead. I am still of the opinion that we want a way to exclude the top level dirs from cleanup, but not the content, and for that a new "X" line would be good. And the other part of the story should then be that PID 1 removes the namespace dirs immediately after the service terminates. (i didn't always agree with that thinking, but Michal convinced me that the correct way to deal with temporary files for every program creating them is to delete them after use and tmpfiles should just be the safety net for leftovers. And if that's the case for every program, then PID 1 has to follow that rule too, and remove the dirs it itself created.) There has been a long-term feature request actually where people asked that programs executed in ExecStartPre=, ExecStart=, ExectStartPost=, ExecStop= should all see the same /tmp. Right now they all get their own. Now, if we need to fix PID 1 to keep track of the namespace dirs in order to remove them eventually we can fix this issue relatively easily at the same time, and reuse the private tmp for all processes of a service, and remove it only if we enter DEAD or FAILED. Kays suggestion of pre-creating a top-level directory in /tmp where all namespaces are placed might be a good idea to implement at the same time actually. It has the nice benefit that userspace code cannot just call its temporary files systemd-privat-xxx and have it excluded from cleanup that easily. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
