[systemd-devel] systemd-tmpfiles for the user instance of systemd
Dan Tihelka
dtihelka at gmail.com
Tue Jul 28 14:42:18 PDT 2015
On Tuesday 28 of July 2015 03:31:08 Lennart Poettering wrote:
> On Sat, 04.07.15 13:23, Tomasz Torcz (tomek at pipebreaker.pl) wrote:
> > On Fri, Jul 03, 2015 at 08:31:42PM +0200, Lennart Poettering wrote:
> > > On Wed, 01.07.15 12:35, Daniel Tihelka (dtihelka at gmail.com) wrote:
> > > > Hello,
> > > > does anyone have an experience with the use of systemd-tmpfiles for
> > > > the user instance of systemd.
> > >
> > > This is currently not nicely supported. And I am not sure it
> > > should. Note that much of what tmpfiles supports is only necessary
> > > for:
> > >
> > > - aging (automatic time-based clean-up of files). Doesn't really apply
> > >
> > > to user sessions, since /tmp and /var/tmp are already cleaned up by
> > > the system instance of tmpfiles
> >
> > /var and /tmp are not only aged files. I'm using tmpfiles for removing
> >
> > – files in ~/Downloads/* older than 1 year
> > – emails in ~/Mail/.spam/cur/* older than 1 month
> >
> > Out of neccessity I have cleanup configured in system instance for my
> >
> > specific user only.
>
> My recommendation would be to clean ~/Downloads up from the root
> tmpfiles instances.
Well, it does not work for encfs (FUSE-based) encrypted directories (root does
not have to have an access to it). An option is to link Downloads (or any
other) to an unencrypted dir, but it somehow violates the purpose of
encryption ... And of course, one must have root access to configure it.
>
> The simple issue is that aging for dirs cannot work, since iterating
> through them will bump the atime, which defeats the aging. You hence
> break the aging by aging... THis can only work if you have root privs,
> since then we can turn off the atime bumping...
Yes, it is documented. But the aging still works for files, doesn't it? Could
it be solved by (optional) deletition of those dirs which stay empty after
files cleaning?
Dan
>
> Lennart
More information about the systemd-devel
mailing list