Bug#942511: systemd: Excludes in tmpfiles.d do not work

Mathias Behrle mbehrle at debian.org
Thu Oct 17 16:15:55 BST 2019


* Michael Biebl: " Re: Bug#942511: systemd: Excludes in tmpfiles.d do not
  work" (Thu, 17 Oct 2019 15:58:47 +0200):


> > First: is 
> > # env SYSTEMD_LOG_LEVEL=debug systemd-tmpfiles --remove
> > the correct way to test the daily cleanup job?  
> 
> No. "--remove" is only run during boot. See
> systemd-tmpfiles-setup.service and systemd-tmpfiles-setup-dev.service
> (those are started via sysinit.target.wants)
> 
> The service that is run regularly via systemd-tmpfiles-clean.timer is
> systemd-tmpfiles-clean.service which uses
> "ExecStart=/bin/systemd-tmpfiles --clean"
> 
> --clean behaves differently then --remove

Ok, I will re-run my tests with the correct parameter to find out what happens.
Thanks a lot for the clarification.
 
> > *If* it is, then something is going wrong *or* is misconfigured,
> > because /tmp is then not only cleaned up at boot, but with the daily
> > cleanup job. 
> >> This Debian specific change was made as this has always been the
> >> behaviour in Debian.
> >>
> >> The documentation for the x/X parameter says:  
> >>>        x
> >>>            Ignore a path during cleaning. Use this type to exclude paths
> >>> from clean-up as controlled with the Age parameter    
> >>
> >>
> >> So x/X having no effect on "D /tmp 1777 root root -" is expected, I'd
> >> say and they work as documented.  
> > 
> > If that is expected behavior what is then the purpose of those lines
> > following
> > 
> > # Exclude namespace mountpoints created with PrivateTmp=yes
> > x /tmp/systemd-private-%b-*
> > X /tmp/systemd-private-%b-*/tmp
> > x /var/tmp/systemd-private-%b-*
> > X /var/tmp/systemd-private-%b-*/tmp
> > 
> > # Remove top-level private temporary directories on each boot
> > R! /tmp/systemd-private-*
> > R! /var/tmp/systemd-private-*
> > 
> > ?
> > 
> > Is this simply cruft?  
> 
> It is cruft, basically. It only makes sense with the upstream default of
> age-based /tmp cleaning. We simply didn't bother to patch that out to
> keep the patch minimal.

Ok. But it is a little bit misleading for users like me not very knowledgable
of systemd.

> >> If you need files to survive a reboot, you should not place them in
> >> /tmp; /var/tmp seems more appropriate in that case.  
> > 
> > I am not talking about files surviving a reboot. I am expecting a
> > clean /tmp on reeboot, too. The files of which I am speaking are cleaned up
> > during the regular run of my workstation (typically running without
> > interruption).  
> 
> A full cleanup of /tmp during regular run-time should not happen.
> As mentioned above, systemd-tmpfiles-clean.service uses "--clean" which
> only does age-based cleanup.
> 
> If something is calling "systemd-tmpfiles --remove" during runtime, then
> this is dangerous and should not happen. Have you seen a package calling
> --remove during runtime?

No, I haven't. I will now re-run my tests and come back to you.


-- 

    Mathias Behrle
    PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
    AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 867 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20191017/93f94307/attachment.sig>


More information about the Pkg-systemd-maintainers mailing list