3

I've just found these directories on my ubuntu PC. How do they come about?

/var/tmp/systemd-private-762c8e6ced154b18ac76720c2c05f2aa-colord.service-fcAgPb
/var/tmp/systemd-private-762c8e6ced154b18ac76720c2c05f2aa-rtkit-daemon.service-iVKzv4
/var/tmp/systemd-private-809e24ac9abd4087b9941b3590575e64-colord.service-KlzdX8
/var/tmp/systemd-private-809e24ac9abd4087b9941b3590575e64-rtkit-daemon.service-mNk1of

The directories each only contain another subdirectory tmp which is always empty.

I mean the filename is kind of self explanatory. systemd probably creates them and they have to do with an rtkit and colord services/demons.

But why does systemd create them? Are these services misconfigured?

Some of these directories are older. Some have a modification time of the last boot.

Can I delete them?

5

These are the effects of a PrivateTmp setting in a service unit. You will find that your rtkit-daemon.service and colord.service units employ that very setting. For why that is, you will have to consult the people who wrote those service unit files. PrivateTmp is after all a band-aid to cover over security holes left by the ways that some programs use /tmp and /var/tmp (excessively privileged use, failure to avoid symbolic link attacks, overwriting anybody's existing files, easily predictable names, excessively open permissions, and so forth). Maybe the security hole has been fixed.

PrivateTmp is implemented, under the covers, by systemd creating a nonce directory under the target temporary directory, and then mounting it in place of the original as a private mount point seen only by the service process(es).

Leaving such directories lying around used to be a systemd bug, that people worked around with tmpfiles.d snippets of their own. It is claimed to have been fixed in your version of systemd. Of course, these directories also get left around by dirty shutdowns.

You can, of course, delete the ones that aren't currently being used by the relevant services.

Further reading

1
  • DIrty shutdowns, yes.
    – knb
    May 24 '15 at 18:49
0

In my case the systemd-private-* directories go back to the date of installation. 1,313 directories to be precise.

$ sudo ll /var/tmp/systemd* | wc -l

1313

To see the oldest:

$ sudo find /var/tmp/systemd*/ -maxdepth 1 -type d -printf "%T@ %Tc %p\n" | sort -n | head -n10

1533569244.0956004300 Mon 06 Aug 2018 09:27:24 AM MDT /var/tmp/systemd-private-832d96941700493c839693111456977a-systemd-timesyncd.service-KcGCS0/
1533569244.0956004300 Mon 06 Aug 2018 09:27:24 AM MDT /var/tmp/systemd-private-832d96941700493c839693111456977a-systemd-timesyncd.service-KcGCS0/tmp
1533854792.8651238050 Thu 09 Aug 2018 04:46:32 PM MDT /var/tmp/systemd-private-8cbe510abc7145faad0ac1066893402d-systemd-timesyncd.service-kcbYN9/
1533854792.8651238050 Thu 09 Aug 2018 04:46:32 PM MDT /var/tmp/systemd-private-8cbe510abc7145faad0ac1066893402d-systemd-timesyncd.service-kcbYN9/tmp
1533854792.9731238090 Thu 09 Aug 2018 04:46:32 PM MDT /var/tmp/systemd-private-8cbe510abc7145faad0ac1066893402d-colord.service-wAL2zb/
1533854792.9731238090 Thu 09 Aug 2018 04:46:32 PM MDT /var/tmp/systemd-private-8cbe510abc7145faad0ac1066893402d-colord.service-wAL2zb/tmp
1533854797.7731240070 Thu 09 Aug 2018 04:46:37 PM MDT /var/tmp/systemd-private-8cbe510abc7145faad0ac1066893402d-rtkit-daemon.service-gWFNlM/
1533854797.7731240070 Thu 09 Aug 2018 04:46:37 PM MDT /var/tmp/systemd-private-8cbe510abc7145faad0ac1066893402d-rtkit-daemon.service-gWFNlM/tmp
1538476157.7205560490 Tue 02 Oct 2018 04:29:17 AM MDT /var/tmp/systemd-private-93ebca0a53c949e7ba1c49e225a5d366-systemd-timesyncd.service-ndLBbW/
1538476157.7205560490 Tue 02 Oct 2018 04:29:17 AM MDT /var/tmp/systemd-private-93ebca0a53c949e7ba1c49e225a5d366-systemd-timesyncd.service-ndLBbW/tmp

I suspend/resume twice a workday and a few times on holidays.I also do software development which can lead to system lockups. Inevitably after a week or so the system crashes. Systemd leaves behind 8 directories, 2 directories for each of these services:

  • systemd-timesyncd.service
  • colord.service
  • rtkit-daemon.service
  • fwupd.service

To see the newest:

$ sudo find /var/tmp/systemd*/ -maxdepth 1 -type d -printf "%T@ %Tc %p\n" | sort -n | tail -n10

1629682894.7751521600 Sun 22 Aug 2021 07:41:34 PM MDT /var/tmp/systemd-private-e1e62fd4795745429b7b84e298dc220e-fwupd.service-OEmxk6/
1629682894.7751521600 Sun 22 Aug 2021 07:41:34 PM MDT /var/tmp/systemd-private-e1e62fd4795745429b7b84e298dc220e-fwupd.service-OEmxk6/tmp
1631968966.2887179850 Sat 18 Sep 2021 06:42:46 AM MDT /var/tmp/systemd-private-e0e32f86f4874cb0907775645f048900-systemd-timesyncd.service-cej24b/
1631968966.2887179850 Sat 18 Sep 2021 06:42:46 AM MDT /var/tmp/systemd-private-e0e32f86f4874cb0907775645f048900-systemd-timesyncd.service-cej24b/tmp
1631968966.4487179920 Sat 18 Sep 2021 06:42:46 AM MDT /var/tmp/systemd-private-e0e32f86f4874cb0907775645f048900-colord.service-kLXvIV/
1631968966.4487179920 Sat 18 Sep 2021 06:42:46 AM MDT /var/tmp/systemd-private-e0e32f86f4874cb0907775645f048900-colord.service-kLXvIV/tmp
1631968972.2567182310 Sat 18 Sep 2021 06:42:52 AM MDT /var/tmp/systemd-private-e0e32f86f4874cb0907775645f048900-rtkit-daemon.service-y3n0R5/
1631968972.2567182310 Sat 18 Sep 2021 06:42:52 AM MDT /var/tmp/systemd-private-e0e32f86f4874cb0907775645f048900-rtkit-daemon.service-y3n0R5/tmp
1631968990.9967190020 Sat 18 Sep 2021 06:43:10 AM MDT /var/tmp/systemd-private-e0e32f86f4874cb0907775645f048900-fwupd.service-ybbQ3L/
1631968990.9967190020 Sat 18 Sep 2021 06:43:10 AM MDT /var/tmp/systemd-private-e0e32f86f4874cb0907775645f048900-fwupd.service-ybbQ3L/tmp

Notice these are from September 18, 2021 which is the last boot time:

$ uptime

 11:48:31 up 8 days,  5:05,  1 user,  load average: 0.60, 1.18, 1.25

Zenity Scrollbox

Reviewing the listing in the terminal is time-consuming so using zenity is helpful:

$ sudo find /var/tmp/systemd*/ -maxdepth 1 -type d -printf "%T@ %Tc %p\n" | sort -n | zenity --text-info --title "Systemd files...$(uptime)" --width 1900 --height 900

systemd private directories.png

The final step will be to find directories older than last boot (8 days ago in my case) and piping output to rm command.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.