How to prevent /tmp files from being deleted at reboot

[MI]

In Debian Jessie, systemd ignores the TMPTIME variable in /etc/default/rcS and just
blindly deletes everything on every reboot.

A bug has been filed about it: "#795269 TMPTIME not honored anymore"
( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795269 )

But I tried the suggested solution, and the files in /tmp still get deleted at reboot.

What I currently have which doesn't work:

$ egrep -v '^(#|$)' /etc/tmpfiles.d/tmp.conf
D /tmp 1777 root root 30d
x /tmp/systemd-private-%b-*
X /tmp/systemd-private-%b-*/tmp
x /var/tmp/systemd-private-%b-*
X /var/tmp/systemd-private-%b-*/tmp


Would someone know what I can do so that only files older than some number of days
get deleted?

[Sven Hartge]

/tmp is most likely a tmpfs, a filesystem in RAM which will vanish (and
all files and directories in it) as soon as the computer is rebooted.

But /tmp being wiped on (re)boot has been the norm and case for
UNIX-based operating systems since nearly forever. No program or user
should expect its/his files to persist in /tmp across a reboot. That is
what /var/tmp is for, a temporary place which will not be wiped upon
reboot.

I regard /tmp being cleared on (re)boot as a feature, not a bug.

The FHS says that "On most systems, this directory is cleared out at
boot or at shutdown by the local system. The basis for this was
historical precedent and common practice. However, it was not made a
requirement because system administration is not within the scope of the
FSSTND. For this reason people and programs must not assume that any
files or directories in /tmp are preserved between invocations of the
program. The reasoning behind this is for compliance with IEEE standard
P1003.2 (POSIX, part 2)."

IMO: If you have a program that relies on files or directories in /tmp
being persistent, then that program is buggy, not Debian.

Grüße,
Sven.

--
Sigmentation fault. Core dumped.

[MI]

> /tmp is most likely a tmpfs, a filesystem in RAM which will vanish (and
> all files and directories in it) as soon as the computer is rebooted.

No, it's a dedicated partition on disk.

> But /tmp being wiped on (re)boot has been the norm and case for
> UNIX-based operating systems since nearly forever. No program or user
> should expect its/his files to persist in /tmp across a reboot. That is
> what /var/tmp is for, a temporary place which will not be wiped upon
> reboot.

Well, we used to have TMPTIME so that everyone could decide for himself how long
"temporary" means.

If it's not possible anymore, it's a regression, and it's a Debian bug anyway, since
the /etc/default/rcS file has a clearly documented setting which is in fact ignored.

But anyway, that's beside the point.

The point is that I cannot get the syntax right to achieve what the systemd
documentation seems to imply: that it is possible to define when a file should be
deleted in number of days, indepentently of arbitrary reboots.

So if someone knows what I'm doing wrong in trying to obtain the documented behavior,
thanks for sharing.

MI


PS:

> IMO: If you have a program that relies on files or directories in /tmp
> being persistent, then that program is buggy, not Debian.

It's not a program. It's just me, mostly while setting up and testing a fresh system,
which may need frequent reboots.

[Linux-Fan]

[Sat, 9 Jul 2016 23:16:29 +0200] MI <mi.list...@alma.ch> wrote:

[...]

Sorry, I can not help with the configuration issue... :(

> PS:
> > IMO: If you have a program that relies on files or directories
> > in /tmp being persistent, then that program is buggy, not Debian.
>
> It's not a program. It's just me, mostly while setting up and testing
> a fresh system, which may need frequent reboots.

...but may I suggest you to use `/var/tmp` as a workaround?
`/var/tmp` is a persistent alternative to `/tmp`.

HTH
Linux-Fan

--
http://masysma.lima-city.de/

[Jörg-Volker Peetz]

On a testing/sid system with sysvinit-core, the script
/etc/init.d/mountall-bootclean.sh (linked to /etc/rcS.d/) calls clean_tmp via
clean_all from /lib/init/bootclean.sh . In this function it says
"Don't clean remaining files if TMPTIME is negative or 'infinite'"

Therefore, to never cleanup set

TMPTIME='infinite'

What is your exact setting in /etc/default/rcS ?

Regards,
jvp.

[MI]

That was how it has "always" worked before. But now systemd ignores TMPTIME, and also
seems to ignore it's own "age" option, unless I'm not using it right.

[Michael Biebl]

Hi

Am 09.07.2016 um 17:03 schrieb MI:
> In Debian Jessie, systemd ignores the TMPTIME variable in
> /etc/default/rcS and just blindly deletes everything on every reboot.
>
> A bug has been filed about it: "#795269 TMPTIME not honored anymore"
> ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795269 )
>
> But I tried the suggested solution, and the files in /tmp still get
> deleted at reboot.

Just to be sure, can you attach the output of
"findmnt".

Do you have any other tmpfiles config files which might override your
custom one.
Can you attach the output of

grep "/tmp" /run/tmpfiles.d/* /usr/lib/tmpfiles.d/* /etc/tmpfiles.d/*

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

[MI]

Hi,

Attached is the output. (BTW, findmnt is cool; I didn't know about it).

Thanks for any insight,

MI

[D. R. Evans]

MI wrote on 07/10/2016 03:04 PM:
> That was how it has "always" worked before. But now systemd ignores TMPTIME, and also
> seems to ignore it's own "age" option, unless I'm not using it right.
>

I am running Jessie, and have
TMPTIME=-1
in /etc/default/rcS

and it still works fine for me.

Doc

--
Web: http://www.sff.net/people/N7DR

[MI]

Sounds promising!

Would you share what you have in /etc/tmpfiles.d/ ? From what I had read, that is
where systemd would read it's tmp settings, and where it would have migrated settings
from rcS on upgades.

You do have a "normal" Debian Jessie with systemd, right? If you uninstalled systemd
or installed a different init system, then of course, you wouldn't have the problem I
have.

Thanks,

MI

[D. R. Evans]

MI wrote on 07/11/2016 09:44 AM:
>
> Sounds promising!
>
> Would you share what you have in /etc/tmpfiles.d/ ? From what I had read, that is
> where systemd would read it's tmp settings, and where it would have migrated settings
> from rcS on upgades.
>

[HN:tmpfiles.d] ls -al
total 20
drwxr-xr-x 2 root root 4096 Aug 25 2015 .
drwxr-xr-x 182 root root 12288 Jul 6 18:06 ..
-rw-r--r-- 1 root root 247 Aug 25 2015 tmp.conf
[HN:tmpfiles.d] cat tmp.conf
# Avoid clearing /tmp by shipping an empty /etc/tmpfiles.d/tmp.conf file
# which overrides /usr/lib/tmpfiles.d/tmp.conf.
# This file was automatically created because of local modifications in
# /etc/default/rcS where TMPTIME was set to infinite.
[HN:tmpfiles.d]

Which is a very confusing message, but I can assure you that /tmp is
definitely NOT cleared.

> You do have a "normal" Debian Jessie with systemd, right?

Completely vanilla Jessie except for ZFS added to support a couple of data disks.

[Michael Biebl]

Am 12.07.2016 um 17:32 schrieb Michael Biebl:
> So, what you copied from the bug report was simply not what you were
> looking at.

looking for, obviously.

[Michael Biebl]

Am 11.07.2016 um 15:22 schrieb MI:
> Hi,
>
> Attached is the output. (BTW, findmnt is cool; I didn't know about it).
>

Thank you. I just wanted to be sure that you weren't using
tmpfs-for-/tmp by default, which isn't the case.

Now to your issue. You said you wanted time based clean-up (remove files
older then 30 days) but *not* remove them on boot.

You've created a file /etc/tmpfiles.d/tmp.conf which overrides the
default that is shipped in /usr/lib/tmpfiles.d/tmp.conf
So far so good. What you used in /etc/tmpfiles.d/tmp.conf is:

D /tmp 1777 root root 30d

Let's see the tmpfiles.d man page [1]:

> D
> Similar to d, but in addition the contents of the directory will be
> removed when --remove is used.

During boot systemd-tmpfiles-setup.service is run:

$ systemctl cat systemd-tmpfiles-setup.service | grep ExecStart
ExecStart=/bin/systemd-tmpfiles --create --remove --boot
--exclude-prefix=/dev

So, you actually requested that /tmp is cleaned up during boot. What you
want is the 'd' option. Again, have a look at the tmpfiles.d man page [2]:

> d
> Create a directory. The mode and ownership will be adjusted if specified and the directory already exists. Contents of this directory are subject to time based cleanup if the time
> argument is specified.

So, what you copied from the bug report was simply not what you were

looking at. Always consult the man pages. The ones shipped by systemd
are actually pretty decent.


I think that should solve your misteries.


Regards,
Michael


[1] https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html#D
[2] https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html#d

[MI]

OK, so you have an empty /etc/tmpfiles.d/tmp.conf which indeed works to completely
avoid cleaning up /tmp at reboot.

That is, it works as an equivalent to TMPTIME=-1. But I do want to cleanup /tmp, just
with some value of TMPTIME > 0.

Anyway, thanks. It at least confirms that the /etc/tmpfiles.d/tmp.conf is indeed
read, and does override the defaults.

MI


-------- Original Message --------

[D. R. Evans]

MI wrote on 07/16/2016 06:53 AM:

>
> That is, it works as an equivalent to TMPTIME=-1. But I do want to cleanup /tmp, just
> with some value of TMPTIME > 0.

That's what tmpreaper is for.

[Michael Biebl]

Am 16.07.2016 um 14:53 schrieb MI:
>
> OK, so you have an empty /etc/tmpfiles.d/tmp.conf which indeed works to
> completely avoid cleaning up /tmp at reboot.
>
> That is, it works as an equivalent to TMPTIME=-1. But I do want to
> cleanup /tmp, just with some value of TMPTIME > 0.
>
> Anyway, thanks. It at least confirms that the /etc/tmpfiles.d/tmp.conf
> is indeed read, and does override the defaults.

Apparently you haven't seen my reply earlier. It's just a
misconfiguration on your part, you want d instead of D

[Michael Biebl]

Am 16.07.2016 um 15:07 schrieb D. R. Evans:
> MI wrote on 07/16/2016 06:53 AM:
>
>>
>> That is, it works as an equivalent to TMPTIME=-1. But I do want to cleanup /tmp, just
>> with some value of TMPTIME > 0.
>
> That's what tmpreaper is for.

tmpreaper is no longer needed or recommended under systemd.
systemd-tmpfiles already does time-based cleanup as builtin feature.

[MI]

Thank you for looking into this.

> Now to your issue. You said you wanted time based clean-up (remove files
> older then 30 days) but *not* remove them on boot.

In fact, cleanup on boot would be fine. However, "cleanup" should only cleanup files
older than the age argument.

I tried these:

- Empty /etc/tmpfiles.d/tmp.conf :

As expected, nothing is cleaned up.

- "D /tmp/ 1777 root root 30d"

Everything is deleted at boot, or when running "systemd-tmpfiles --create
--remove --clean"
Also with "~30d" instead of "30d".

- "d /tmp/ 1777 root root 30d"

Nothing is deleted at boot or when running "systemd-tmpfiles --create --remove
--clean" without a reboot.

# grep ' /tmp' /etc/tmpfiles.d/tmp.conf
d /tmp 1777 root root 30d
x /tmp/systemd-private-%b-*
X /tmp/systemd-private-%b-*/tmp
# reboot
...
# ls -Al /tmp/
total 36
...
-rw-rw-r-- 1 root root 8 Jul 16 15:21 KEEPTHIS.txt
-rw-rw-r-- 1 root root 9 Jan 1 2016 TOOOLD.txt
...

So the age argument seems to always be ignored?

And I find no way to get the old (before systemd) behaviour: cleanup /tmp at boot,
but preserve "recent" files

If this is the expected behaviour, then either the documentation is quite unclear and
misleading, or I'm too dumb to understand it (which is actually quite possible...)

MI

[Michael Biebl]

Am 16.07.2016 um 16:06 schrieb MI:

> - "d /tmp/ 1777 root root 30d"
>
> Nothing is deleted at boot or when running "systemd-tmpfiles --create
> --remove
> --clean" without a reboot.
>
> # grep ' /tmp' /etc/tmpfiles.d/tmp.conf
> d /tmp 1777 root root 30d
> x /tmp/systemd-private-%b-*
> X /tmp/systemd-private-%b-*/tmp
> # reboot
> ...
> # ls -Al /tmp/
> total 36
> ...
> -rw-rw-r-- 1 root root 8 Jul 16 15:21 KEEPTHIS.txt
> -rw-rw-r-- 1 root root 9 Jan 1 2016 TOOOLD.txt
> ...

Please post the output of
stat /tmp/TOOOLD.txt

[MI]

> Please post the output of
> stat /tmp/TOOOLD.txt

# stat /tmp/TOOOLD.txt
File: ‘/tmp/TOOOLD.txt’
Size: 9 Blocks: 8 IO Block: 4096 regular file
Device: 805h/2053d Inode: 14 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2016-01-01 12:23:00.000000000 +0100
Modify: 2016-01-01 12:23:00.000000000 +0100
Change: 2016-07-16 15:21:28.806601066 +0200
Birth: -

[Mark Fletcher]

I suspect it is the Change line that is doing it -- although I wonder what the difference between Change and Modify is...

Mark

[Michael Biebl]

There are 3 kind of "timestamps":

Access - the last time the file was read
Modify - the last time the file was modified (content has been modified)
Change - the last time meta data of the file was changed (e.g.
permissions)

So, some process changed the files! metadata, that's why it's not
deleted. Everything working as expected from the systemd-tmpfiles POV.



Regards,
Michael

[D. R. Evans]

Michael Biebl wrote on 07/16/2016 07:25 AM:

>
> tmpreaper is no longer needed or recommended under systemd.
> systemd-tmpfiles already does time-based cleanup as builtin feature.
>

Thank you for that information (which was news to me), but in any case I would
far rather rely on a separate program to perform this job than any init system.

(I find it hard to see why this would or should be the job of an init system.
An init system can reasonably be assigned the task of deleting things at boot;
but after that I don't see that an init system has any business messing with
the files in /tmp.)

[MI]

Yes, it looks like it's the ctime which prevents the deletion, and "d /tmp ... xxd"
is indeed the option which is the closest to the old behaviour.

I guess I will have to get used to the "systemd POV" ...

Thanks all for your help

MI




-------- Original Message --------

[Michael Biebl]

systemd-tmpfiles is a distinct binary as is tmpreaper.

We ship it as part of the systemd package because it's useful
functionality to have in a base system. Strictly speaking, the
tmpfiles.d mechanism is not tied to a particular init. It's just that
no-one has provided an implementation for non-systemd. Though we
certainly had requests already to provide that.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812215

[Josh Triplett]

Michael Biebl wrote:
> Now to your issue. You said you wanted time based clean-up (remove files
> older then 30 days) but *not* remove them on boot.
>
> You've created a file /etc/tmpfiles.d/tmp.conf which overrides the
> default that is shipped in /usr/lib/tmpfiles.d/tmp.conf
> So far so good. What you used in /etc/tmpfiles.d/tmp.conf is:
>
> D /tmp 1777 root root 30d
>
> Let's see the tmpfiles.d man page [1]:
>
> > D
> > Similar to d, but in addition the contents of the directory will be
> > removed when --remove is used.
>
> During boot systemd-tmpfiles-setup.service is run:
>
> $ systemctl cat systemd-tmpfiles-setup.service | grep ExecStart
> ExecStart=/bin/systemd-tmpfiles --create --remove --boot
> --exclude-prefix=/dev
>
> So, you actually requested that /tmp is cleaned up during boot. What you
> want is the 'd' option. Again, have a look at the tmpfiles.d man page [2]:
>
> > d
> > Create a directory. The mode and ownership will be adjusted if specified and the directory already exists. Contents of this directory are subject to time based cleanup if the time
> > argument is specified.
>
>
> So, what you copied from the bug report was simply not what you were
> looking at. Always consult the man pages. The ones shipped by systemd
> are actually pretty decent.

My first mail to that bug report, at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795269#10 , had a bug
in the patch: it migrates the TMPTIME setting to the appropriate line,
but it doesn't change 'D' to 'd', so /tmp still gets wiped on boot. I
sent an updated patch to the bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795269#22

Please consider applying that updated patch to the systemd postinst.

- Josh Triplett

[Jonathan de Boyne Pollard]

Michael Biebl:

> There are 3 kind of "timestamps":
> Access - the last time the file was read
> Modify - the last time the file was modified (content has been modified)
> Change - the last time meta data of the file was changed (e.g. permissions)

Not on all flavours of Debian. Debian FreeBSD has 4.

* http://superuser.com/a/703927/38062

[Jonathan de Boyne Pollard]

Michael Biebl: > Strictly speaking, the tmpfiles.d mechanism is not tied

to a particular init. It's just that no-one has provided an
implementation for non-systemd.

Untrue. The OpenRC people have had a tmpfiles utility since 2012.

[Michael Biebl]

I didn't know that. Thanks for the info.
Can you post some more details? Where can I find the sources for that?
Is it packaged for Debian?

Regards,
Michael

[Jonathan de Boyne Pollard]

Jonathan de Boyne Pollard:

> Untrue. The OpenRC people have had a tmpfiles utility since 2012.

Michael Biebl:

> I didn't know that. Thanks for the info.
> Can you post some more details? Where can I find the sources for that?
> Is it packaged for Debian?

Here's the Gentoo OpenRC repository:

* https://gitweb.gentoo.org/proj/openrc.git/log/sh/tmpfiles.sh.in

Here's a mirror:

* https://github.com/OpenRC/openrc

Here are the Debian packages:

* https://tracker.debian.org/pkg/openrc

[Wilko Fokken]

On Sun, Jul 10, 2016 at 03:32:12PM +0200, Linux-Fan wrote:
> [Sat, 9 Jul 2016 23:16:29 +0200] MI <mi.list...@alma.ch> wrote:

> > > IMO: If you have a program that relies on files or directories
> > > in /tmp being persistent, then that program is buggy, not Debian.
> >
> > It's not a program. It's just me, mostly while setting up and testing
> > a fresh system, which may need frequent reboots.
>
> ...but may I suggest you to use `/var/tmp` as a workaround?
> `/var/tmp` is a persistent alternative to `/tmp`.
>
> HTH
> Linux-Fan


I set the following link (in single user mode):


– – – – – – – – – – –

rm -rf /tmp

chmod 1777 /var/TMP

ln -s /var/TMP /tmp



Additionly I altered /etc/default/rcS:

# TMPTIME=0

TMPTIME=8

– – – – – – – – – – –

So far, my system seems to be running smoothly; (with MANY reboots a day
as I am trying out a cohabitation of my favourite old 'icewm' with Debians
chosen xfce4-wm.)

My oldest files and directories in '/tmp' date from july 31.

(Hoping my answer won't be redundant, as only skimmed my mails in a rush.)


Regards Wilko