On 2021-03-17 01:52:36 Till Dörges wrote:

|Am 16.03.21 um 19:26 schrieb DennisG: |> At boot, my /tmp directory is being cleaned out.  However, /var/tmp/ |> still has ~3000 folders, containing ~300 files.  All but 2 of the |> folders are named zypp.*, created over the past 2 years and appear to |> contain mostly public/private keys and associated files. |> |> My /etc/tmpfiles.d/tmp.conf looks like (as recommended on the Forums): |> |> D! /tmp 1777 root root 1d |> D! /var/tmp 1777 root root 1d |> |> So it would appear that the first line for /tmp is being used (I presume |> by a systemd unit), but the second line is not.  My |> /usr/lib/tmpfiles.d/tmp.conf has: |> |> d /tmp 1777 root root - |> d /var/tmp 1777 root root - |> |> which I have understood is the installed default and is not used when |> tmp.conf exists under /etc/tmpfiles.d/ (?). |> |> What am I missing? | |I've encountered the same issue, but didn't get around to pursuing it. | | |My *guess* is that it's actually a bug in the configuration files, i.e. | the path "/var/tmp" is listed twice: | |--- snip --- |$ \grep -Hrn 'var/tmp ' /usr/lib/tmpfiles.d/* |/usr/lib/tmpfiles.d/fs-var.conf:9:d /var/tmp 1777 root - |/usr/lib/tmpfiles.d/tmp.conf:13:q /var/tmp 1777 root root - |--- snip --- | |and apparently installing a custom version of "tmp.conf" doesn't cut it, | because it's late to the party: | |Mar 16 21:47:29 box systemd-tmpfiles[14015]: [/etc/tmpfiles.d/tmp.conf:12] | Duplicate line for path "/var/tmp", ignoring. | | |So you probably have to install a custom version of "fs-var.conf" and | configure your retention policy for /var/tmp there. | | |And maybe filing a bug at https://bugzilla.opensuse.org/ is a good idea, | too. | | |HTH -- Till

One wonders why both /tmp and /var/tmp exist. Is one of them deprecated? Leslie -- openSUSE Leap 15.2 x86_64

Am 17.03.21 um 20:05 schrieb Carlos E. R.:

On 17/03/2021 19.33, J Leslie Turriff wrote:

...

On 2021-03-17 01:52:36 Till Dörges wrote:

...

|Am 16.03.21 um 19:26 schrieb DennisG:

...

...

    One wonders why both /tmp and /var/tmp exist.  Is one of them deprecated?

No. One is long term and the other short term.

And depends on your installation one is now ramdrive as i think i remember a discussion a factory@ if your installation has it as ramdrive its normal that it will be after new start empty. simoN -- www.becherer.de

Am Mittwoch, 17. März 2021, 20:39:47 CET schrieb J Leslie Turriff:

On 2021-03-17 14:10:30 Simon Becherer wrote:

...

|Am 17.03.21 um 20:05 schrieb Carlos E. R.: |> On 17/03/2021 19.33, J Leslie Turriff wrote: |>> On 2021-03-17 01:52:36 Till Dörges wrote: |>>> |Am 16.03.21 um 19:26 schrieb DennisG: |> ... |> |>> One wonders why both /tmp and /var/tmp exist. Is one of them |>> deprecated? |> |> No. One is long term and the other short term. | |And depends on your installation one is now ramdrive as i think i |remember |a discussion a factory@ |if your installation has it as ramdrive its normal that it will be |after new start empty. | |simoN

So which is which? Long-term/Short-term, RAM drive/physical drive?

Leslie

/tmp is short-term and in RAM by default now, but not for old installations. You need to migrate those manually: https://en.opensuse.org/openSUSE:Tmp_on_tmpfs regards

On 2021-03-17 16:23:56 Peter McD wrote:

|Am 17.03.21 um 20:39 schrieb J Leslie Turriff: |> On 2021-03-17 14:10:30 Simon Becherer wrote: |>> |Am 17.03.21 um 20:05 schrieb Carlos E. R.: |>> |> On 17/03/2021 19.33, J Leslie Turriff wrote: |>> |>> On 2021-03-17 01:52:36 Till Dörges wrote: |>> |>>> |Am 16.03.21 um 19:26 schrieb DennisG: |>> |> |>> |> ... |>> |> |>> |>>     One wonders why both /tmp and /var/tmp exist.  Is one of them |>> |>> deprecated? |>> |> |>> |> No. One is long term and the other short term. |>> | |>> |And depends on your installation one is now ramdrive as i think i |>> | remember a discussion a factory@ |>> |if your installation has it as ramdrive its normal that it will be |>> |after new start empty. |>> | |>> |simoN |> |> So which is which? Long-term/Short-term, RAM drive/physical drive? | |tmp is short term. tmp could be set up in RAM as tmpfs, I think default |ist max half of RAM and cleared automatically when powered down. |Could fill up in computers running permanently, so tmp in |/etc/tmpfiles.d/tmp.conf is not obsolete. | |In my computer tmp it is a line in fstab and takes a max of 20% of RAM, | |tmpfs /tmp tmpfs size=20%,mode=1777 0 0 | |Peter

Interesting. My machine shows | ● mount|grep ^tmpfs | tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) | tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) | tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) | tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3274328k,mode=700,uid=1000,gid=100) | tmpfs on /run/user/1001 type tmpfs (rw,nosuid,nodev,relatime,size=3274328k,mode=700,uid=1001,gid=1001) | tmpfs on /run/user/1003 type tmpfs (rw,nosuid,nodev,relatime,size=3274328k,mode=700,uid=1003,gid=100) I like the idea of using a percentage; is that an easy change? Leslie -- openSUSE Leap 15.2 x86_64

Am 17.03.21 um 07:52 schrieb Till Dörges:

Am 16.03.21 um 19:26 schrieb DennisG:

...

At boot, my /tmp directory is being cleaned out.  However, /var/tmp/ still has ~3000 folders, containing ~300 files.  All but 2 of the folders are named zypp.*, created over the past 2 years and appear to contain mostly public/private keys and associated files.

My /etc/tmpfiles.d/tmp.conf looks like (as recommended on the Forums):

D! /tmp 1777 root root 1d D! /var/tmp 1777 root root 1d [...] What am I missing?

I've encountered the same issue, but didn't get around to pursuing it.

My *guess* is that it's actually a bug in the configuration files, i.e. the path "/var/tmp" is listed twice: [...] And maybe filing a bug at https://bugzilla.opensuse.org/ is a good idea, too.

Apparently there already was a bug in bugzilla. And even better, it seems to have just been fixed (this is on openSUSE Leap 15.2): --- snip --- $ rpm -q filesystem filesystem-15.0-lp152.11.3.1.x86_64 $ rpm -q --changelog filesystem [...] * Fr Sep 04 2020 Thorsten Kukuk - Split /var/tmp out of fs-var.conf, new file is fs-var-tmp.conf. Allows to override config to add cleanup options of /var/tmp [bsc#1078466] - Create fs-tmp.conf to cleanup /tmp regular (required with tmpfs) [bsc#1175519] [...] --- snip --- Regards -- Till -- Dipl.-Inform. Till Dörges doerges@pre-sense.de PRESENSE Technologies GmbH Nagelsweg 41, D-20097 HH Geschäftsführer/Managing Directors AG Hamburg, HRB 107844 Till Dörges, Jürgen Sander USt-IdNr.: DE263765024

Am 31.03.21 um 23:28 schrieb DennisG:

On 3/29/21 3:32 AM, Till Dörges wrote:

...

Am 17.03.21 um 07:52 schrieb Till Dörges:

...

Am 16.03.21 um 19:26 schrieb DennisG:

...

At boot, my /tmp directory is being cleaned out.  However, /var/tmp/ still has ~3000 folders, containing ~300 files.  All but 2 of the folders are named zypp.*, created over the past 2 years and appear to contain mostly public/private keys and associated files.

My /etc/tmpfiles.d/tmp.conf looks like (as recommended on the Forums):

D! /tmp 1777 root root 1d D! /var/tmp 1777 root root 1d [...] What am I missing?

What I did: tmpfs is installed, two lines in /etc/tmpfiles.d/tmp.conf q /tmp 1777 root root - q /var/tmp 1777 root root - Log out as user <Strg><Alt><F1> Log in as root init 1 (root level 1, maintenance level, requires again root password) change to /tmp/ rm -r * rm -r .* change to /var/tmp/ rm -r * rm -r .* reboot(!!) everything is cleared in both directories , and hasn't come back yet, except the daily files. Be aware, if you make a mistake with "rm" you can crash your system. Peter

Am 02.04.21 um 07:26 schrieb J Leslie Turriff:

On 2021-04-01 01:30:16 Peter McD wrote:

...

|What I did: | |tmpfs is installed, two lines in |/etc/tmpfiles.d/tmp.conf | |q /tmp 1777 root root - |q /var/tmp 1777 root root -

What is 'q'? I have no such command on my system.

copied from /etc/tmpfiles.d/tmp.conf # See tmpfiles.d(5) for details man tmpfiles.d q Similar to v. However, makes sure that the subvolume will be assigned to the same higher-level quota groups as the subvolume it has been created in. This ensures that higher-level limits and accounting applied to the parent subvolume also include the specified subvolume. On non-btrfs file systems, this line type is identical to d. Peter

Am 01.04.21 um 08:30 schrieb Peter McD:

What I did:

tmpfs is installed, two lines in /etc/tmpfiles.d/tmp.conf

q /tmp 1777 root root - q /var/tmp 1777 root root - [...] everything is cleared in both directories , and hasn't come back yet, except the daily files.

Your configuration via /etc/tmpfiles.d/tmp.conf won't delete anything, because you have a - (dash) in the last column (see 'man tmpfiles.d' and search for "age"). I assume it's working for you, because IIUC both /var/tmp and /tmp are mounted as tmpfs (filesystem in RAM) on your machine. IOW they are emptied upon every shutdown. :-) Regards -- Till -- Dipl.-Inform. Till Dörges doerges@pre-sense.de PRESENSE Technologies GmbH Nagelsweg 41, D-20097 HH Geschäftsführer/Managing Directors AG Hamburg, HRB 107844 Till Dörges, Jürgen Sander USt-IdNr.: DE263765024

Am 03.04.21 um 13:39 schrieb Peter McD:

Anyway I change

q /var/tmp 1777 root root 1d

two reboots

and /var/tmp still gets cleared?

Yes, that's what I'd expect. But beware that you have to edit the correct configuration file. After the change in the filesystem RPM it should be /etc/tmpfiles.d/fs-var-tmp.conf (rather than /etc/tmpfiles.d/tmp.conf) HTH -- Till -- Dipl.-Inform. Till Dörges doerges@pre-sense.de PRESENSE Technologies GmbH Nagelsweg 41, D-20097 HH Geschäftsführer/Managing Directors AG Hamburg, HRB 107844 Till Dörges, Jürgen Sander USt-IdNr.: DE263765024

On 4/3/21 12:02 PM, Peter McD wrote:

Am 03.04.21 um 16:44 schrieb Till Dörges:

...

Am 03.04.21 um 13:39 schrieb Peter McD:

...

Anyway I change q /var/tmp 1777 root root 1d two reboots and /var/tmp still gets cleared?

Yes, that's what I'd expect. But beware that you have to edit the correct configuration file. After the change in the filesystem RPM it should be /etc/tmpfiles.d/fs-var-tmp.conf (rather than /etc/tmpfiles.d/tmp.conf)

So I move from /usr/lib/tmpfiles.d/fs-var-tmp.conf to /etc/tmpfiles.s/

and modify # d /var/tmp 1777 root root -  to d /var/tmp 1777 root root 1d

I expect after a reboot older folders/files. e.g. drwx------ 3 root root 4096  3. Apr 17:40 systemd-private-6704694542b3421f8612991315fd7962-chronyd.service-RNsuvq

But several reboots later there are only the  folders/files with the same /date/time of the latest boot time.

e.g. drwx------ 3 root root 4096  3. Apr 17:56 systemd-private-6d19ab9a0f284936a9177444417f38b8-chronyd.service-33ZqOB

What is wrong?

Peter

I'm not sure I understand your question.  Perhaps this may help . . . "The age of a file system entry is determined from its last modification time (mtime), its last access timestamp (atime), and (except for directories) its last status change timestamp (ctime). Any of these three (or two) values will prevent cleanup if it is more recent than the current time minus the age field." To see what systemd-tmpfiles is doing, do: #env SYSTEMD_LOG_LEVEL=debug systemd-tmpfiles --clean You will see the exceptions.  E.g., systemd folders are skipped because a glob in an earlier config file has protected it; some files will be skipped because they are actually a "live socket" (like sddm*); some files/folders may be updated by the systemd process itself before the clean executes, such as runtime-root. Your "1d" age parameter should work fine.  Just note however that there are programs which will put a file under /tmp that it will use as long as it is open but will not be protected from deletion, this can happen with X.  Consequently, deleting that file can crash or lock that program.  So when I was once testing using an age of 1h, I crashed X.  "1d" should avoid this, but even with that I did once see an application program with a file in /tmp that was >day old, and it locked when that file was deleted (I suspect this is very rare, though). Of course if you boot daily that avoids such problems.  An alternative that guarantees the cleaning will only happen at boot, despite whenever systemd-tmpfiles may be run, is to place a "!" after the "d" command (i.e., "d!") and change the systemd-tmpfiles-clean.service file to add the "--boot" flag.  This way systemd-tmpfiles will always ignore the cleaning command except at boot. HTH, --dg

Am 03.04.21 um 23:28 schrieb DennisG:

On 4/3/21 12:02 PM, Peter McD wrote:

...

Am 03.04.21 um 16:44 schrieb Till Dörges:

...

Am 03.04.21 um 13:39 schrieb Peter McD:

...

Anyway I change q /var/tmp 1777 root root 1d two reboots and /var/tmp still gets cleared?

Yes, that's what I'd expect. But beware that you have to edit the correct configuration file. After the change in the filesystem RPM it should be /etc/tmpfiles.d/fs-var-tmp.conf (rather than /etc/tmpfiles.d/tmp.conf) So I move from /usr/lib/tmpfiles.d/fs-var-tmp.conf to /etc/tmpfiles.s/

and modify # d /var/tmp 1777 root root -  to d /var/tmp 1777 root root 1d

I expect after a reboot older folders/files. e.g. drwx------ 3 root root 4096  3. Apr 17:40 systemd-private-6704694542b3421f8612991315fd7962-chronyd.service-RNsuvq But several reboots later there are only the  folders/files with the same /date/time of the latest boot time. e.g. drwx------ 3 root root 4096  3. Apr 17:56 systemd-private-6d19ab9a0f284936a9177444417f38b8-chronyd.service-33ZqOB What is wrong?

I'm not sure I understand your question.  Perhaps this may help . . .

I assumed that setting "d /var/tmp 1777 root root 1d" will clean at the earliest 24h after creation whatever is in "/var/tmp" unless it has been accessed by any system activity. A new test. I copied a dummy.txt to /var/tmp, rebooted and bingo it is still there, I expect it to be deleted after 1 day. I could have set, as you did to 1h, but I think "d" works as intended.

"The age of a file system entry is determined from its last modification time (mtime), its last access timestamp (atime), and (except for directories) its last status change timestamp (ctime). Any of these three (or two) values will prevent cleanup if it is more recent than the current time minus the age field." ... Your "1d" age parameter should work fine.  Just note however that there are programs which will put a file under /tmp that it will use as long as it is open but will not be protected from deletion, this can happen with X.  Consequently, deleting that file can crash or lock that program.  ...

Of course if you boot daily that avoids such problems.  An alternative that guarantees the cleaning will only happen at boot, despite whenever systemd-tmpfiles may be run, is to place a "!" after the "d" command (i.e., "d!") and change the systemd-tmpfiles-clean.service file to add the "--boot" flag.  This way systemd-tmpfiles will always ignore the cleaning command except at boot.

Ok, I thinl to be safe it is better to use "d!" on my computer. Thanks Peter

On 4/4/21 7:56 AM, Dave Howorth wrote:

On Sat, 3 Apr 2021 17:28:48 -0400 DennisG wrote:

...

Just note however that there are programs which will put a file under /tmp that it will use as long as it is open but will not be protected from deletion If a program does that, then it should simply keep the file open whilst it is running. If it does that then it will continue to have access to the file even if it is deleted from the filesystem.

Maybe should, but not necessarily, will.  X (and presumably, other programs) writes files to /tmp that are not protected.  If deleted before it is replaced with a new file (I don't know what triggers that), the server crashes.  I encountered this in tests using age "1h".   So essentially, this calls for the same caution that is recommended with using e.g. r, R, or age zero - i.e., timing is critical. --dg

On 4/4/21 1:35 PM, Carlos E. R. wrote:

On 04/04/2021 19.10, DennisG wrote:

...

On 4/4/21 7:56 AM, Dave Howorth wrote:

...

On Sat, 3 Apr 2021 17:28:48 -0400 DennisG wrote:

...

Just note however that there are programs which will put a file under /tmp that it will use as long as it is open but will not be protected from deletion If a program does that, then it should simply keep the file open whilst it is running. If it does that then it will continue to have access to the file even if it is deleted from the filesystem.

Maybe should, but not necessarily, will.  X (and presumably, other programs) writes files to /tmp that are not protected.  If deleted before it is replaced with a new file (I don't know what triggers that), the server crashes.  I encountered this in tests using age "1h".   So essentially, this calls for the same caution that is recommended with using e.g. r, R, or age zero - i.e., timing is critical.

Wouldn't those files have been accessed at least once during the current machine uptime?

The cleaning routine should not delete any file which has one of the three timestamps shorter than the current uptime.

You are quite right.  Using the X server as an example . . . There are 2 types of X files written to /tmp when the server starts, an xauth* which is tied to the display number and a differently formatted xauth* which is tied to some session activity.  Since my last boot the former xauth* file has been renewed (i.e., same filename) several times, updating /all 3/ timestamps each time - the most current being ~3 hours ago.   I have 4 files of the latter types, each created and accessed periodically since boot, with 1 having had all 3 timestamps updated ~5 hours ago. Running systemd-tmpfiles with an age flag set to 1h, the xauth* file tied to the display was deleted, as were 3 of the 4 other xauth* files.  Depending on the activity, when X found the files missing it created replacements, other times it locked the app and crashed the server.  This can happen with other programs/apps, e.g. in one test I killed KDE and in another I killed Pulse. Of course these are extreme examples.  I added that remark to my post just as a clarification for the OP, in line with the wiki warning about not removing needed /tmp files while in a session, which can happen with the age flag set too short or worse yet, using zero.  Unlikely, yes.  But possible. --dg

On 4/4/21 5:25 PM, Carlos E. R. wrote:

On 04/04/2021 22.25, DennisG wrote:

...

On 4/4/21 1:35 PM, Carlos E. R. wrote:

...

On 04/04/2021 19.10, DennisG wrote:

...

On 4/4/21 7:56 AM, Dave Howorth wrote:

...

On Sat, 3 Apr 2021 17:28:48 -0400 DennisG wrote:

...

Just note however that there are programs which will put a file under /tmp that it will use as long as it is open but will not be protected from deletion If a program does that, then it should simply keep the file open whilst it is running. If it does that then it will continue to have access to the file even if it is deleted from the filesystem.

Maybe should, but not necessarily, will.  X (and presumably, other programs) writes files to /tmp that are not protected.  If deleted before it is replaced with a new file (I don't know what triggers that), the server crashes.  I encountered this in tests using age "1h".   So essentially, this calls for the same caution that is recommended with using e.g. r, R, or age zero - i.e., timing is critical.

Wouldn't those files have been accessed at least once during the current machine uptime?

The cleaning routine should not delete any file which has one of the three timestamps shorter than the current uptime.

You are quite right.  Using the X server as an example . . .

There are 2 types of X files written to /tmp when the server starts, an xauth* which is tied to the display number and a differently formatted xauth* which is tied to some session activity.  Since my last boot the former xauth* file has been renewed (i.e., same filename) several times, updating /all 3/ timestamps each time - the most current being ~3 hours ago.   I have 4 files of the latter types, each created and accessed periodically since boot, with 1 having had all 3 timestamps updated ~5 hours ago.

Running systemd-tmpfiles with an age flag set to 1h, the xauth* file tied to the display was deleted, as were 3 of the 4 other xauth* files. Depending on the activity, when X found the files missing it created replacements, other times it locked the app and crashed the server. This can happen with other programs/apps, e.g. in one test I killed KDE and in another I killed Pulse.

Of course these are extreme examples.  I added that remark to my post just as a clarification for the OP, in line with the wiki warning about not removing needed /tmp files while in a session, which can happen with the age flag set too short or worse yet, using zero.  Unlikely, yes. But possible.

The problem (to me) seems that the age flag must be dynamically set to something larger than the current uptime, not a fixed value.

If we can not do that somehow, I prefer to leave the thing disabled.

Right.  My solution was to add the exclamation point (d!) to /etc/tmpfiles.d/fs-tmp.conf and fs-var-tmp.conf, add --boot to systemd-tmpfiles-clean.service, and comment out OnUnitActiveSec in /usr/lib/systemd/system/systemd-tmpfiles-clean.timer.  That cleans /tmp and /var/tmp with every boot.  (I understand that you already know this, I'm just including the details for anyone who may later read this thread.) --dg

On 4/4/21 6:06 PM, Dave Howorth wrote:

On Sun, 4 Apr 2021 16:25:14 -0400 DennisG wrote:

...

On 4/4/21 1:35 PM, Carlos E. R. wrote:

...

On 04/04/2021 19.10, DennisG wrote:

...

...

On Sat, 3 Apr 2021 17:28:48 -0400 DennisG wrote:

...

Just note however that there are programs which will put a file under /tmp that it will use as long as it is open but will not be protected from deletion If a program does that, then it should simply keep the file open whilst it is running. If it does that then it will continue to have access to the file even if it is deleted from the filesystem. Maybe should, but not necessarily, will.  X (and presumably, other

On 4/4/21 7:56 AM, Dave Howorth wrote: programs) writes files to /tmp that are not protected.  If deleted before it is replaced with a new file (I don't know what triggers that), the server crashes.  I encountered this in tests using age "1h".   So essentially, this calls for the same caution that is recommended with using e.g. r, R, or age zero - i.e., timing is critical. Wouldn't those files have been accessed at least once during the current machine uptime?

The cleaning routine should not delete any file which has one of the three timestamps shorter than the current uptime.

You are quite right.  Using the X server as an example . . .

There are 2 types of X files written to /tmp when the server starts, an xauth* which is tied to the display number and a differently formatted xauth* which is tied to some session activity.  Since my last boot the former xauth* file has been renewed (i.e., same filename) several times, updating /all 3/ timestamps each time - the most current being ~3 hours ago.   I have 4 files of the latter types, each created and accessed periodically since boot, with 1 having had all 3 timestamps updated ~5 hours ago. Err, I'm sitting here typing this mail in an X session:

# ls -l /tmp total 4 -r--r--r-- 1 root root 11 Mar 17 14:30 .X0-lock drwxrwxrwt 1 root root 4 Mar 17 14:30 .X11-unix srwxr-xr-x 1 dhoworth users 0 Mar 17 14:30 .pcmanfm-socket--0-dhoworth srwxr-xr-x 1 dhoworth users 0 Mar 20 11:19 OSL_PIPE_1000_SingleOfficeIPC_2c139c358aa808ba56150309b273129 drwx------ 1 dhoworth users 64 Apr 4 21:09 claws-mail-1000 drwx------ 1 dhoworth users 22 Apr 4 21:12 firefox drwx------ 1 dhoworth users 20 Mar 17 14:30 ssh-t2p7Ucvz2L46 drwx------ 1 dhoworth users 20 Mar 17 14:30 ssh-tOiEo97kMLfN drwx------ 1 root root 6 Mar 17 14:30 systemd-private-8f940ab862e84761900565a3bdeaae33-apache2.service-mh7U89 drwx------ 1 root root 6 Mar 17 14:30 systemd-private-8f940ab862e84761900565a3bdeaae33-ntpd.service-oUZrzc drwx------ 1 root root 6 Mar 17 14:30 systemd-private-8f940ab862e84761900565a3bdeaae33-redis@default.service-r91TIl

No xauth files at all ????

...

Running systemd-tmpfiles with an age flag set to 1h, the xauth* file tied to the display was deleted, as were 3 of the 4 other xauth* files. Depending on the activity, when X found the files missing it created replacements, other times it locked the app and crashed the server. This can happen with other programs/apps, e.g. in one test I killed KDE and in another I killed Pulse.

Of course these are extreme examples.  I added that remark to my post just as a clarification for the OP, in line with the wiki warning about not removing needed /tmp files while in a session, which can happen with the age flag set too short or worse yet, using zero. Unlikely, yes. But possible.

--dg

I have no idea.  When I did my testing, I was looking only at the consequences of using different Type and Age parameters. I have noticed that running some apps results in an xauth* file (second type) being created but then deleted when the app closes, while others when run will have a file created but not deleted when the app is closed, and yet for others there is no new xauth* file created at all.  And something periodically accesses or updates the file tied to the display.   My wild guess is that this varies with the DE (I'm using KDE) and the individual programs. --dg

On 4/3/21 5:41 PM, Till Dörges wrote:

Am 03.04.21 um 18:02 schrieb Peter McD:

...

So I move from /usr/lib/tmpfiles.d/fs-var-tmp.conf to /etc/tmpfiles.s/

and modify # d /var/tmp 1777 root root -  to d /var/tmp 1777 root root 1d

I expect after a reboot older folders/files. e.g. drwx------ 3 root root 4096  3. Apr 17:40 systemd-private-6704694542b3421f8612991315fd7962-chronyd.service-RNsuvq

But several reboots later there are only the  folders/files with the same /date/time of the latest boot time.

e.g. drwx------ 3 root root 4096  3. Apr 17:56 systemd-private-6d19ab9a0f284936a9177444417f38b8-chronyd.service-33ZqOB

What is wrong?

I didn't find anything in the documentation but according to https://unix.stackexchange.com/questions/219814/why-is-systemd-tmpfiles-clea... systemd also seems to take the access (atime) and inode change timestamp (ctime) into account - and not only the modification timestamp (mtime).

That means, if you look at a file (to check whether it's still there) you might also change the atime or ctime of the directory.

To understand what's going on, try this:

  SYSTEMD_LOG_LEVEL=debug /usr/bin/systemd-tmpfiles --clean

One thing you could try is (from 'man tmpfiles.d'):

--- snip --- When the age is set to zero, the files are cleaned unconditionally. --- snap ---

HTH -- Till

We were typing at the same time.  :) If age is set to zero, then IME it becomes critical that the cleaning only runs at boot.  If it runs during a session it will among others things delete the files that X and sddm depend on, killing them both.  I would only use 0 with the exclamation point (d! or e!), as in the example on the man page. --dg