The wisdom of emptying /tmp at boot time

[robin_listas]

On 2014-08-14 23:56, wolfi323 wrote:
>
> tsu2;2659229 Wrote:
>> Aside from it now being deployed as tmpfs, I think it was in the 12.3
>> notes(someone needs to check exactly when) the tmp directory was cleared
>> automatically on shutdown anyway.
>>
> That’s plain wrong.
>
> /tmp IS NOT and NEVER WAS setup as tmpfs on openSUSE.
>
> And it is not cleaned by default either, at least not in 13.1:
> See the shipped /usr/lib/tmpfiles.d/tmp.conf:

True.

The old cronjob we had was more powerful than the new systemd method.
More customizable. So now they chose the lest dangerous route: delete
nothing.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

[wolfi323]

@robin_listas

> Which, AIUI, at boot time deletes all files and dirs older than 1 day in
> the /tmp/ directory. If I changed the number to 0 (zero), all files and
> dirs would be deleted.

I’m unsure when it is done. Only at boot, or periodically? I think the
later.

As systemd-tmpfiles-clean.timer is active by default (it is static), it should be cleaned periodically, yes.

And /usr/lib/systemd/system/systemd-tmpfiles-clean.timer contains this:

[Timer]
OnBootSec=15min
OnUnitActiveSec=1d

So the cleanup should be run 15 minutes after the system booted up, and then every day afterwards.

[hcvv]

I am getting more and more attrackted by the solution the OP posted in his first post above. Make a crontab entry for root:

@reboot cd /tmp; rm -fr *

The advantages:

• it will do what you want;
• you understand what it does en when and why;
• it will work with all Unix/Linux tastes and versions as long as cron is supported;
• no need of understanding anything about the old way that was made to make configuring this easy (the pre-created cron job, it’s config file and the YaST interface);
• no need of understanding the new way: systemd, the concept of the tmpfiles.d files, the many other new configuration files (the number involved seem to grow with every post here), the lack of YaST interface to make things easy.

The disadvantages:

• you need some knowledge of cron and a few shell commands.

For me the choice looks easy.

[wolfi323]

@robin_listas

On 2014-08-15 12:06, wolfi323 wrote:

> Yes.
> You could of course just copy over the file in /etc/cron.daily from an
> earlier openSUSE version, then those variables would have effect
> again…

That’s something I’m considering doing…

Here’s /etc/cron.daily/suse.de-clean-tmp from 12.2:

#!/bin/sh
#
#
# clean_tmp. This script was split off cron.daily
# Please add your local changes to cron.daily.local
# since this file will be overwritten, when updating your system.
#
# Copyright (c) 1996-2002 SuSE Linux AG, Nuernberg, Germany.
#
# please send bugfixes or comments to http://www.suse.de/feedback.
#
# Author: Burchard Steinbild, 1996
#         Florian La Roche, 1996
#


#
# paranoia settings
#
umask 022


PATH=/sbin:/bin:/usr/sbin:/usr/bin
export PATH
#
# get information from /etc/sysconfig
#
if  -f /etc/sysconfig/cron ] ; then
    . /etc/sysconfig/cron
fi


#
# Delete apropriate files in tmp directories.
#
OMIT=""
for i in $OWNER_TO_KEEP_IN_TMP ; do
    OMIT="$OMIT  ( ! -user $i )"
done


cleanup_tmp ()
{
  MAX_DAYS=$1
  shift
  DIRS_TO_CLEAR="$@"
 
  if  "$MAX_DAYS" -gt 0 ]; then
    for DIR in $DIRS_TO_CLEAR ; do
      test -x /usr/bin/safe-rm && {
      find $DIR/. -xdev $OMIT ! -type d ! -type s ! -type p \
        \( -atime +$MAX_DAYS -a -ctime +$MAX_DAYS \) -exec /usr/bin/safe-rm {} \;
      } || echo "Error: Can not find /usr/bin/safe-rm"
      find $DIR/. -xdev -depth -mindepth 1 $OMIT -type d -empty \
        \( -mtime +$MAX_DAYS -a -ctime +$MAX_DAYS \) -exec /usr/bin/safe-rmdir {} \;
    done
  fi 
}


cleanup_tmp ${MAX_DAYS_IN_TMP:-0} ${TMP_DIRS_TO_CLEAR:-/tmp}
cleanup_tmp ${MAX_DAYS_IN_LONG_TMP:-0} ${LONG_TMP_DIRS_TO_CLEAR}


exit 0

Create a file in /etc/cron.daily/ with this content (the actual name doesn’t really matter), “chmod +x” it, and your /tmp and /var/tmp should be cleaned according to the variables in /etc/sysconfig/cron again.
You might have to restart cron, but I think it will even recognize automatically that a new file has been added.

[robin_listas]

On 2014-08-15 13:46, wolfi323 wrote:

>> I’m unsure when it is done. Only at boot, or periodically? I think the
>> later.
>>
> As systemd-tmpfiles-clean.timer is active by default (it is static), it
> should be cleaned periodically, yes.
>
> And /usr/lib/systemd/system/systemd-tmpfiles-clean.timer contains this:
>
> Code:
> --------------------
> [Timer]
> OnBootSec=15min
> OnUnitActiveSec=1d
> --------------------
>
> So the cleanup should be run 15 minutes after the system booted up, and
> then every day afterwards.

And if the machine is not running at that time one day later, but
hibernated, when does it happen? It could be some time after waking up,
or it could skip it till that original time the next day. And if this
happens several days in a row, does it eventually run?

You see, the old cron script job did all that, and it was configurable.
Last time I asked this, the systemd people just booed me.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

[idanan]

@hcvv

Two questions:

1. Isn’t there a typo in the third field (tmps
   fs)? When yes, then does it work, or did you not copy/paste as you suggest with the CODE tags? 1. As the permission bits for /tmp should include the t-bit, shouldn’t you have added the mode=1777 option?

Good catch. Yes, it’s a typo. I wasn’t pasting because I had fstab open on one machine and replying from another

Never thought about the mode, it’s been working for a year with the programs I use, so it is not essential. Maybe it will affect some programs?

Thanks!

• Itai

[wolfi323]

@robin_listas

And if the machine is not running at that time one day later, but
hibernated, when does it happen? It could be some time after waking up,
or it could skip it till that original time the next day. And if this
happens several days in a row, does it eventually run?

If I understand the documentation correctly, the timer is suspended during hibernation.

From “man systemd.timer”:

           These are monotonic timers, independent of wall-clock time and
           timezones. If the computer is temporarily suspended, the monotonic
           clock stops too.

So as I understand that, if you hibernate the system 12 hours after boot (or rather after the service ran the last time), the temp files would be cleaned 12 hours after the resume, regardless of how long the system was hibernated/suspended.

You see, the old cron script job did all that, and it was configurable.

No. Cron did that.

The script only checked the owner and age of the files according to the environment variables.
Cron has to take care of running the script, which it does once a day because it is in cron.daily.

Your questions would actually be the same:

And if the machine is not running at that time one day later, but
hibernated, when does it happen? It could be some time after waking up,
or it could skip it till that original time the next day. And if this
happens several days in a row, does it eventually run?

And the answers to those questions might depend on which of the several cron implementations is actually used.

[robin_listas]

On 2014-08-15 14:06, hcvv wrote:
>
> I am getting more and more attrackted by the solution the OP posted in
> his first post above. Make a crontab entry for root:
>
> Code:
> --------------------
> @reboot cd /tmp; rm -fr *
> --------------------
>
> The advantages:

It has one big problem: At the moment it runs, systemd and other things
are already running and posibly using files in /tmp, which will be then
deleted. So you should instead use find with an age limit, so that files
younger than, say, the last hour, are untouched.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

[hcvv]

@idanan

Good catch. Yes, it’s a typo. I wasn’t pasting because I had fstab open on one machine and replying from another

Never thought about the mode, it’s been working for a year with the programs I use, so it is not essential. Maybe it will affect some programs?

Thanks!

• Itai

The t-bit is essential for directories like /tmp.

The restricted deletion flag or sticky bit is a single bit, whose interpretation depends on the file type. For directories, it prevents unprivileged users from removing or renaming a file in the directory unless they own the file or the directory; this is called the restricted deletion flag for the directory, and is commonly found on world-writable directories like /tmp.

In other words it prevents user B to delete files that were put there by user A. Which is normaly possible with files in a directory like /tmp

henk@boven:~> ls -ld /tmp
drwxrwxrwt 17 root root 12288 15 aug 16:30 /tmp
henk@boven:~>

where the w-bit is set for the world and thus everybody can create and delete files in that directory, irrespective of the fact they own that file or not.

It is quite possible that you never experienced the negative effects of your security flaw in not having this restriction when you have in fact only one user storing and deleting things in /tmp (or you have users with very good behaviour). But as these threads are consulted by many people, the correct setting of the permission bits of /tmp and the like is very worthwhile to mention IMHO.

[hcvv]

@robin_listas

On 2014-08-15 14:06, hcvv wrote:
>
> I am getting more and more attrackted by the solution the OP posted in
> his first post above. Make a crontab entry for root:
>
> Code:
> --------------------
> @reboot cd /tmp; rm -fr *
> --------------------
>
> The advantages:

It has one big problem: At the moment it runs, systemd and other things
are already running and posibly using files in /tmp, which will be then
deleted. So you should instead use find with an age limit, so that files
younger than, say, the last hour, are untouched.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

You are correct. It may be too rigorous.

Using the old script posted above might be better then. I did not study it, but taken the fact that it is already used for years, I assume it caters for such problems.

[robin_listas]

On 2014-08-15 16:36, wolfi323 wrote:

>> You see, the old cron script job did all that, and it was configurable.
> No. Cron did that.
>
> The script only checked the owner and age of the files according to the
> environment variables.
> Cron has to take care of running the script, which it does once a day
> because it is in cron.daily.

No, it triggered ever 15 minutes, then it checked things to find out
when was the last actual run, and if it was a day before, it could run
that instant, or wait till the system configured preferred time (on the
administrator choice). If at time the system wasn’t up, it would
postpone up to three days (configurable), and then it would run at the
first chance.

It was not that simple a cron job, you see, but a complex script created
by SUSE people

> Your questions would actually be the same:
>> And if the machine is not running at that time one day later, but
>> hibernated, when does it happen? It could be some time after waking up,
>> or it could skip it till that original time the next day. And if this
>> happens several days in a row, does it eventually run?
>>
> And the answers to those questions might depend on which of the several
> cron implementations is actually used.

No, I was asking what systemd does: I know pretty well what the openSUSE
cron implementation does

You answered that above: it runs a day later, counted as system running
time. Wich is also a bit unclear. if a machine runs just 2 hours a day,
when will the cleaning job runs?

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

[robin_listas]

On 2014-08-15 14:06, wolfi323 wrote:
>
> robin_listas;2659309 Wrote:
>> On 2014-08-15 12:06, wolfi323 wrote:
>>
>>> Yes.
>>> You could of course just copy over the file in /etc/cron.daily from an
>>> earlier openSUSE version, then those variables would have effect
>>> again…
>>
>> That’s something I’m considering doing…
>>
> Here’s /etc/cron.daily/suse.de-clean-tmp from 12.2:

which is run from /usr/lib/cron/run-crons, which is called from
/etc/crontab. The cron.daily scripts are not simply run “daily” on openSUSE.

> You might have to restart cron, but I think it will even recognize
> automatically that a new file has been added.

No need to restart anything. Actually, restarting it does not trigger
job run, you have to delete the files in “/var/spool/cron/lastrun”.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

[robin_listas]

On 2014-08-15 16:56, hcvv wrote:

> Using the old script posted above might be better then. I did not study
> it, but taken the fact that it is already used for years, I assume it
> caters for such problems.

Well, “/etc/cron.daily/suse.de-clean-tmp” only deletes old files. The
delete on boot action was done by “/etc/init.d/boot.cleanup”, and it
knows nothing about systemd tmp files, being an older design. But it was
not a simple script either, it was complex: I’m looking at the one on
11.4. It did not delete everything.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

[tsu2]

Well,
If /tmp isn’t being cleane automatically today then I would simply go back to what I was running before 12.3…

Install and run tmpwatch.

No need to set cron jobs, just modify the config file to point to whatever directories you want purged on a regular basis and when.

Very simple and probably more capable than the manual recipes I see posted.

TSU

[wolfi323]

@robin_listas

On 2014-08-15 16:36, wolfi323 wrote:

>> You see, the old cron script job did all that, and it was configurable.
> No. Cron did that.
>
> The script only checked the owner and age of the files according to the
> environment variables.
> Cron has to take care of running the script, which it does once a day
> because it is in cron.daily.

No, it triggered ever 15 minutes, then it checked things to find out
when was the last actual run, and if it was a day before, it could run
that instant, or wait till the system configured preferred time (on the
administrator choice). If at time the system wasn’t up, it would
postpone up to three days (configurable), and then it would run at the
first chance.

No, the cleaning script is not triggered every 15 minutes.

Or are you speaking about run-crons now?
That’s not specific to cleaning /tmp though, but it exists to actually run the cron jobs in /etc/cron.daily and so on.
Still it would only run the cron job (all of the daily ones) once a day, either at the fixed time set in /etc/sysconfig/cron or (if that is unset) 15 minutes after booting the system.

And there’s this in /etc/sysconfig/cron of course:

# Maximum days not running when using a fixed time set in DAILY_TIME.
# 0 to skip this. This is for users who will power off their system.
#
# There is a fixed max. of 14 days set,  if you want to override this
# change MAX_NOT_RUN_FORCE in /usr/lib/cron/run-crons
MAX_NOT_RUN="5"

But you mentioned that anyway.

It was not that simple a cron job, you see, but a complex script created
by SUSE people

I think we are talking about different things then.

I already posted the cron job that was part of 12.2.
What do you mean? run-crons?
Then you are not talking about the /tmp cleaning script now, but about openSUSE’s cron itself.

But you wrote:

You see, the old cron script job did all that, and it was configurable.

I thought you really meant the cron job script (that I posted) with “old cron script job”.
That sentence was at least a bit ambiguous I would say…

> Your questions would actually be the same:
>> And if the machine is not running at that time one day later, but
>> hibernated, when does it happen? It could be some time after waking up,
>> or it could skip it till that original time the next day. And if this
>> happens several days in a row, does it eventually run?
>>
> And the answers to those questions might depend on which of the several
> cron implementations is actually used.

No, I was asking what systemd does: I know pretty well what the openSUSE
cron implementation does

And I answered you. At least I quoted the documentation and how I interpret it.

You answered that above: it runs a day later, counted as system running
time. Wich is also a bit unclear. if a machine runs just 2 hours a day,
when will the cleaning job runs?

15 minutes after you turned it on.

If you only hibernate, it wil take 12 days for it to run again I suppose.
But if it is not running, nothing will create temporary files either…

[wolfi323]

@tsu2

Well,
If /tmp isn’t being cleane automatically today then I would simply go back to what I was running before 12.3…

It is being cleaned automatically, but you have to configure/enable it.

Again, this is not enabled by default and never was in openSUSE.

[robin_listas]

On 2014-08-15 18:56, wolfi323 wrote:
>
> tsu2;2659379 Wrote:
>> Well,
>> If /tmp isn’t being cleane automatically today then I would simply go
>> back to what I was running before 12.3…
>>
> It is being cleaned automatically, but you have to configure/enable it.

The available configuration by systemd is far less tunable than what it
was previously by openSUSE cron scripts.

> Again, this is not enabled by default and never was in openSUSE.

True.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

[robin_listas]

On 2014-08-15 18:56, wolfi323 wrote:

> No, the cleaning script is not triggered every 15 minutes.
>
> Or are you speaking about run-crons now?

The daily cron jobs, actually all of the daily cron scripts, are run not
by cron directly, but by the run-crons script, which was called by cron
every 15 minutes. Thus the need to run the daily delete tmp files script
was evaluated every 15 minutes.

> I think we are talking about different things then.

No, actually the same thing

>
> I already posted the cron job that was part of 12.2.
> What do you mean? run-crons?
> Then you are not talking about the /tmp cleaning script now, but about
> openSUSE’s cron itself.
>
> But you wrote:
>> You see, the old cron script job did all that, and it was configurable.
> I thought you really meant the cron job script (that I posted) with “old
> cron script job”.
> That sentence was at least a bit ambiguous I would say…

Yes, that’s true.

>> No, I was asking what systemd does: I know pretty well what the openSUSE
>> cron implementation does
> And I answered you. At least I quoted the documentation and how I
> interpret it.

Yes, I know, I read that documentation myself, but it is clear as mud to me.

>
>> You answered that above: it runs a day later, counted as system running
>> time. Wich is also a bit unclear. if a machine runs just 2 hours a day,
>> when will the cleaning job runs?
>>
> 15 minutes after you turned it on.
>
> If you only hibernate, it wil take 12 days for it to run again I
> suppose.
> But if it is not running, nothing will create temporary files either…
>

Ok, I mean this.

Suppose I boot at 00:00, for simplicity.

At 00:15, systemd would delete all /tmp files older than 1 day (with the
config that jimoe666 posted:

d /tmp 1777 root root 1d

ie, not exactly at boot, and not everything.

At 02:00, I hibernate.

At 22:00, I power it up again (thaw).
At 23:00, I hibernate.

At 06:00, thaw.

Does clean up happen at 06:15? I guess not, because the machine has not
been running 24 hours, despite the uptime command saying “1 day, 6 hours”

I guess that clean up would happen whenever 24 hours actual running time
is reached, right? Could be today, or in weeks, if the machine only runs
one hour per day.

You see, the “definition” is not clear at all

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

[wolfi323]

@robin_listas

> I think we are talking about different things then.

No, actually the same thing

No. What you described is done by run-crons.
I was talking about the actual script that cleans /tmp, which is called by cron/run-crons once a day.

Does clean up happen at 06:15? I guess not, because the machine has not
been running 24 hours, despite the uptime command saying “1 day, 6 hours”

That’s how I understand it, yes.
It won’t run it on 06:15, because that was no boot.

I guess that clean up would happen whenever 24 hours actual running time
is reached, right? Could be today, or in weeks, if the machine only runs
one hour per day.

Yes, that’s what I think.

You see, the “definition” is not clear at all

Well, “cron”'s definition was not clear at all either (as I said there are several implementations with possibly differing behavior). ;=)
AFAIK the original cron didn’t run jobs at all that are scheduled for a time when the system is not running.
SUSE’s run-crons script might in fact be necessary only because of missing features in cron…

OTOH, it actually depends on the job at hand which bahavior would be the correct one in such a case.
F.e. if you have a job that plays a jingle at 12h to remind you that it’s 12 o’clock, it makes no sense to run that later when the machine was turned off/hibernated at that time.
So it’s hard/impossible to define a behavior that’s correct under all circumstances.
But at least there is a well-defined behavior in systemd.timer.

Btw, it is possible to tell systemd.timer to run the service every day at 12:30 f.e., or hourly, yearly, … similar to cron :

  OnCalendar=
       Defines realtime (i.e. wallclock) timers via calendar event

expressions. See systemd.time(7) for more information on the syntax
of calendar event expressions. Otherwise the semantics are similar
to OnActiveSec= and related settings.

No idea what exactly that means in the case that the system is not running at that time though…:\

But I think this is getting far off-topic now. The thread is about cleaning /tmp at boot time. Not about how cron/systemd.timer should behave.

[wolfi323]

@robin_listas

The available configuration by systemd is far less tunable than what it
was previously by openSUSE cron scripts.

You are talking about run-crons again, right? Not about the actual tmp cleaning.

For the cleaning I see only the following options with the old script:

• you can set after how many days files should be removed (MAX_DAYS_IN_TMP, MAX_DAYS_IN_LONG_TMP)
  This is configurable with the systemd unit as well, even more flexible because you can specify the age for each folder. With the old cron script you only had two sets, TMP and LONG_TMP.

• you can specify which directories should be cleaned (TMP_DIRS_TO_CLEAR, LONG_TMP_DIRS_TO_CLEAR)
  Again, perfectly possible with systemd’s tmpfiles configuration.

• you can exclude files that are owned by specific users (OWNER_TO_KEEP_IN_TMP)
  I think this is not possible with systemd.

• you can force the dirs to be cleaned at boot (CLEAR_TMP_DIRS_AT_BOOTUP), but this ignores everything else, i.e. age and owner, it just runs “rm -rf” unconditionally on boot for the specified directories or the TMP directories if unspecified…
  You can do this with a systemd unit/tmpfiles.d config as well of course. If you specify a ‘D’ instead of ‘d’ in the tmp.conf line, the directory will get emptied on boot.

The time when daily jobs are run do not really belong to the options for the tmpfile cleaning job. Those are global cron options.
But this should be possible with systemd as well, if you adapt the .timer unit file.

So I wouldn’t say that the systemd configuration is far less tunable.

But if you prefer the old cron job, just use it. Nobody prevents you from doing that.