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