systemd /tmp cleaning is suboptimal

I personally have become very accustomed to the current behavior where /tmp is emptied on reboot -- I have no idea what most users would say about this, so I wonder if changing that behavior would be unwelcome. I do think it could be nice to have the 30d behavior back, however.

In other words, if we did change this I think my preference would be:

 D /tmp 1777 root root 30d

so that we still always clear on boot, but also after 30d if needed.

On the other hand, this feels like it might be something that most people don't care about, and those that do are welcome to change their local system.

The reason it's specifically important to me not to clean at boot is that schroot bind mounts /tmp by default but does not bind mount /var/tmp by default, so I am accustomed (since long before the systemd behavior became the norm) to using this directory for sharing data between the host system and chroots and relying on it persisting across reboots (since it's not old). (And I don't use /home because it's stuff I *do* want garbage-collected for me - just not at reboot!)

When you say you've "become very accustomed to the current behavior where /tmp is emptied on reboot" - how would it impact you if it was NOT cleaned at reboot?

(setting bug back to New because I don't see any request for information)

> how would it impact you if it was NOT cleaned at reboot?

I just like it. It's easier for me to keep track in my head that "oh, this file in /tmp will only be around until I reboot", as opposed to trying to keep track of the actual age of a file. To be clear, I am not suggesting that my use case is strong argument for keeping the current default (I will happily write an /etc/tmpfiles.d/tmp.conf drop-in to meet my preference if needed). Just pointing out that there might be a range of preferences on the default handling of /tmp.

Also, you may have already come across this, but if not, this is the Debian bug that resulted in the current default: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675422.

If you think it would be best for most Ubuntu users to change the current default, then we should go with your suggested change. If the motivation is mostly about your schroot use case, then I would suggest either modifying schroot to do what you need, or using /etc/tmpfiles.d/tmp.conf.

The Ubuntu QA team encountered an issue where our autopkgtest-cloud-workers in the prod-proposed-migration environment ran out of free space in /tmp because these are production servers which are rebooted very infrequently. Due to some bug in the autopkgtest-cloud or autopkgtest code there were left over log files from late November, December, and January in /tmp. These log files can be quite large and our 200G /tmp partition ended up being full quite regularly.

I too would expect /tmp to be cleaned up regularly and remember the days when it was.

It would be interesting to see what other server administrators do about cleaning up /tmp. Does everyone modify /usr/lib/tmpfiles.d/tmp.conf ?

FWIW I agree with Nick's preference (clean at boot && clean files older than 30d). Maybe we could make that 40d, as 30d is likely to be a time interval at which a lot of periodic things happen (e.g. an off-site backup). A retention period >30d is less likely be synchronized with it in an unlucky way.

Mounts with relatime (the default) update the atime unconditionally if the previous atime is >1day old, so no issues with that.

You say "Nick's preference", but it's Nick who took the position here that the default behavior should not change?

On Fri, Feb 16, 2024 at 01:06:07PM -0000, Paride Legovini wrote:
> Maybe we could make that 40d, as 30d is likely to be a time interval at
> which a lot of periodic things happen (e.g. an off-site backup).

The period here is the age at which files are considered old and to be clean
up, not the interval at which the clean-up happens.

Also fwiw I have edited my /usr/lib/tmpfiles.d/tmp.conf locally (using a
diversion) since this bug was moving forward and it doesn't actually seem to
be working.

$ grep -v ^# /usr/lib/tmpfiles.d/tmp.conf

d /tmp 1777 root root 30d
$ sudo find /tmp -type f -mtime +30 | wc -l
130319
$ sudo find /tmp -atime +30 | wc -l
8
$ sudo find /tmp -ctime +30 | wc -l
744
$

So at least on desktop I have something that is regularly changing
ctime/atime on the contents of /tmp and therefore preventing them from being
garbage collected...

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
<email address hidden> <email address hidden>

AIUI he suggests keeping the boot time cleanup, and that it could be nice to have the 30d behavior back. In any case that's what I'd prefer. I know we're speaking of file age; certainly not of blindly deleting everything every month or so :-)

It looks like something on our autopkgtest-cloud-worker may also be regularly changing the contents of /tmp but we've set up an experiment for over the weekend and will report back.

Looks like the experiment worked: having

  e /tmp 1777 root root 30d

deleted a test directory which has mtime and atime >30d old (done via: touch -d '29 days ago', and then left to age over the weekend).

I agree with Nick, regular cleaning *and* cleaning at /boot is best behavior.

I have uploaded a change to add the 30d cleanup age.

This bug was fixed in the package systemd - 255.4-1ubuntu5

---------------
systemd (255.4-1ubuntu5) noble; urgency=medium

  * No-change rebuild against libcurl4t64

 -- Steve Langasek <email address hidden> Sat, 16 Mar 2024 07:04:30 +0000