[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