clear /tmp at boot doesn't work is systemd

I’ve been wondering why my /tmp directory was so full and just noticed that CLEAR_TMP_DIRS_AT_BOOTUP doesn’t work in systemd. I don’t know if it has been mentioned already. I just rebooted in system V and /tmp is empty now. Maybe /etc/sysconfig/cron is not used at all.

  • /tmp is on a separate partition (again).

I posted about this yesterday

There was a bug report files back at Beta stage

Reported as bug 721682

Good. I was going to try to figure out something. But I see different workarounds already in the bug report.

OK. Here’s what I did:

I created the file /etc/tmpfiles.d/tmp.conf with the following content:

#  This file overwrites systemd defaults in /usr/lib/tmpfiles.d/tmp.conf
# **See tmpfiles.d(5) for details**

# Clears /tmp and /var/tmp and creates /tmp/.cache
D /tmp 1777 root root 1s
D /var/tmp 1777 root root 1s
d /tmp/.cache 1777 root root 1s

Notice that I instructed it to create the directory /tmp/.cache in the last line, because I need this directory. In System V, I’m still using ugly commands to do this.

CLEAR_TMP_DIRS_AT_BOOTUP is ignored by systemd but systemd-tmpfiles achieves the same thing. All I did was overwrite the defaults in /usr/lib/tmpfiles.d/tmp.conf:

#  This file is part of systemd.
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.

# See tmpfiles.d(5) for details

# Clear tmp directories separately, to make them easier to override
d /tmp 1777 root root 10d
d /var/tmp 1777 root root 30d

The “workaround” you suggested on your blog is just other way to deal with temporary files. If you’re not writing anything in /tmp on the filesystem, obviously you don’t need to clear anything.

There are files created in “/tmp”, even if not directly by me. Some of these are reused after a reboot. Some of them are deleted when the application shuts down. But some of them have random names, are not deleted when the application shuts down, and thus accumulate.

I originally started using “tmpfs” for “/tmp” because that way, together with encrypted swap, I could reduce the problems of unencrypted data being left behind on the disk. That’s no longer as important, since I am using an encrypted LVM with the effect that the root file system is encrypted.

On 01/03/2012 07:56 PM, nrickert wrote:
> Some of these are reused after a reboot.

maybe, but the ‘convention’ (as i understand it) is that anything of a
temporary nature which should persist after a boot is be directed (by
the program developer) to /var/tmp/, and nothing in /tmp should be
expected to remain though a boot…

openSUSE®, the “German Engineered Automobiles” of operating systems!

I agree, and was not suggesting otherwise.

What is reused, is the directory entry (or file name), not the content. And deleting the name is fine, but it will be recreated.

My intended point was that those files are not a problem if not cleaned up. It’s the ones with random names that accumulate and make “/tmp” messy to scan through.

If you use RAM instead of filsesystem for /tmp, there is nothing to clear in /tmp at boot because there is nothing left when you reboot. I thought it was obvious enough. But you know that already. So what was the point of explaining to us that /tmp gets filled with random files under Linux? Are you suggesting we never noticed?

As I understand this thread:

  1. systemd does not follow the documented actions concerning /tmp files at boot time, whereas the predecessor systemv adheres to these standards

  2. temporary (F5, change to systemv) allows for clenup of /tmp

  3. There are several novel and imaginative circumventions to resolve the problem, most likely beyond the ken of novice users

What is the resolution to the problem ? I have booted with systemv, and /tmp is cleared as expected. Although the boot process is a bit longer, systemv does offer the presence of /var/log/boot.msg as well as more verbose boot detail(s). The availability of this log, alone, is worth the boot override to systemv. The lack of adherence to documented boot parameters is usually (and unfortunately) resolved by simply revising said documentation. I do hope such an easy path is not the solution.

If all you want is to clear /tmp while booting in systemd, the solution I posted in #5 will work. However @6tr6tr has reported problem while using /etc/tmpfiles.d/tmp.conf: I can not explain why. I works fine for me (on 4 machines - 32 and 64bit). It’s actually not even a hack. You’ll just overwrite the default settings (from /usr/lib/tmpfiles.d/tmp.conf).

Possibly permissions problem?

You set the permissions in tmp.conf. So if he used the file I provided, he must have the same permissions.
tmp.conf has to be owned by root though… well, it was obvious but… :\

Okay, I tried this on one system. I didn’t add the “/tmp/.cache”. I used the “D” on on “/tmp”.

I left the times at their original (10d rather than 1s for “/tmp”).

That seems to already be enough to clear “/tmp” at boot.

Yes, /tmp/.cache was just in my own example, but I didn’t delete this line to show the difference between D and d.

I don’t know if it means that only files older than 10 days (rather than 1 second) will be deleted. But - logically - this setting should not clear /tmp if you reboot today or tomorrow. (?)

My reading of the man page for “tmpfiles.d” is that the “D” indicates that the directory should be emptied. So I tried that.

I commented out my fstab entry for a tmpfs mount. I copied “tmp.conf” to “/etc/tmpfiles.d” and then changed the “d” to a “D” for the entry for “/tmp”. Then I rebooted.

That was yesterday afternoon. A check showed that “/tmp” was the plain directory, part of the root file system, and that it only had new files. Well, that’s no test because “/tmp” was already empty.

I booted again this morning. Again, it had only new files. There was nothing left behind from yesterday. And some of the files that I saw yesterday were ones that I expected to see left around if “/tmp” was not cleared.

Thus far, it supports my reading. The “D” flag is the important one for clearing on boot. The time indicator on that line is only there to satisfy the syntax requirements for lines in that file.

I’ll continue to monitor that over the next few reboots. After that, I may go back to using tmpfs.

You’re right. The time indicator is ignored with the “D” flag. I replaced “1s” with “10d” and rebooted and /tmp was cleared.

So, in the final analysis, what is the generic fix for this issue (In its entirety)?

Thank You,

I think CLEAR_TMP_DIRS_AT_BOOTUP is one of the bugs fixed in the most recent systemd update, glancing at the changelog. Another is /etc/sysconfig/kernel:MODULES_LOADED_AT_BOOT I think. But I’ve reverted to sysvinit for other reasons.

The /etc/tmpfiles.d/tmp.conf I posted is a acceptable workaround. The only problem is that it doesn’t reflect the settings in /etc/sysconfig/cron. So the fix is probably to get the list of directories based on (LONG)TMP_DIRS_TO_CLEAR and time based on MAX_DAYS_IN(LONG)TMP and pass it or not to systemd-tmpfiles depending on the value of CLEAR_TMP_DIRS_AT_BOOTUP. Maybe that’s what they did, as @ken_yap mentioned they got it fixed.