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

[Michael Biebl]

Am 17.10.19 um 15:19 schrieb Mathias Behrle:
> * Michael Biebl: " Re: Bug#942511: systemd: Excludes in tmpfiles.d do not
>   work" (Thu, 17 Oct 2019 13:33:50 +0200):
> 
> Hi Michael,
> 
> thanks for your immediate response.
> 
>> Am 17.10.19 um 13:09 schrieb Mathias Behrle:
>>> Package: systemd
>>> Version: 242-7
>>> Severity: important
>>>
>>> Dear Maintainers,
>>>
>>> since considerable time I encounter the problem, that tmp
>>> files/directories created by vim are obviously deleted by systemd-tmpfiles.
>>> While searching for the reason I found the following facts:
>>>
>>> /usr/lib/tmpfiles.d/tmp.conf contains
>>> # Clear tmp directories separately, to make them easier to
>>> override D /tmp 1777 root root -
>>>
>>> This line is introduced by
>>> https://salsa.debian.org/systemd-team/systemd/blob/experimental/debian/patches/debian/Bring-tmpfiles.d-tmp.conf-in-line-with-Debian-defaul.patch
>>> and replaces
>>> q /tmp 1777 root root 10d
>>>
>>> So good so far, now to the reason of this bug report:
>>> The current behavior on my system is, that regardless of any excludes
>>> the tmp directory is cleaned radically, verified by running
>>> # env SYSTEMD_LOG_LEVEL=debug systemd-tmpfiles --remove
>>>
>>> So I was not able to prevent the deletion of any files by defining excludes
>>> like X /tmp/v*
>>> x /tmp/v*
>>>
>>> Also the predefined excludes in /usr/lib/tmpfiles.d/tmp.conf do not
>>> work, i.e. those files are cleaned up when existing. So I think that
>>> there is definitely a bug in systemd-tmpfiles.  
>>
>>
>> Maybe this is a misunderstanding how x/X is supposed to work.
>> "D /tmp 1777 root root -" is supposed to clean up /tmp during boot
>> unconditionally. It is *not* using age based cleaning.
> 
> Yes, may be.
> 
> 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

> *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.

>> 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?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20191017/5f43b522/attachment.sig>