Kay Sievers píše v St 17. 10. 2012 v 18:28 +0200: > On Wed, Oct 17, 2012 at 6:10 PM, Lennart Poettering > <lenn...@poettering.net> 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