The wisdom of emptying /tmp at boot time

[Fraser_Bell]

@wolfi323

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

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

… ummhh? Wolfi?

Could you please make up my mind for me???

To my following statement:

                 https://forums.opensuse.org/images/misc/quote_icon.png Originally Posted by **Fraser_Bell**                     https://forums.opensuse.org/images/buttons/viewpost-right.png](https://forums.opensuse.org/showthread.php?p=2659257#post2659257)                 
             ... and not in 12.1 nor 12.3, either.  I doubt it ever was cleaned by default.

You said:

Well, it was indeed cleaned by default on 12.3, when systemd-tmpfiles was introduced.

… and, now, again – for at least the 2nd or 3rd time – you say:

@wolfi323

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

… it must be one or the other, not both ways.:\

[wolfi323]

@Fraser_Bell

… it must be one or the other, not both ways.:\

Right.
Automatic cleaning of /tmp and /var/tmp was indeed enabled in 12.3 (I forgot to repeat this again in the post you mention), 12.3 shipped with the upstream default tmp.conf.

But there were complaints from users that lost their “data” because of that, so that has been changed again for 13.1.

But 12.3 was the only exception AFAIK. It was never enabled by default before that.

And /tmp was never a tmpfs at all (in openSUSE).

Clear now?

[robin_listas]

On 2014-08-15 20:56, wolfi323 wrote:
>
> robin_listas;2659399 Wrote:
>>> 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.

Yes, same as me.

Cron parses /etc/crontab, which has an entry to run run-crons, which
then runs /etc/cron.daily/suse.de-clean-tmp.

Cron never calls any script in /etc/cron.daily/ directly.

>> 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.

Correct.

> SUSE’s run-crons script might in fact be necessary only because of
> missing features in cron…

Yes, that is so.
There is an alternative cron daemon which does, though: anacron.

> 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.

I prefer the suse implementation of cron scripts. In my scenario above
of hibernation, it would still run at my preferred hour range, but
another day. With systemd, the actual time of running delays for several
days, even weeks.

>
> 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.

Ah? That is interesting.

> 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.

Well, if we want to write/insert a deletion job, we have to know where
and how to do it…

–
Cheers / Saludos,

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

[robin_listas]

On 2014-08-15 21:36, wolfi323 wrote:
>
> robin_listas;2659390 Wrote:
>> 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.

The tmp cleaning that is activated by run-crons.

> - 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.

With a more complicated syntax. You have to read manuals.

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

Correct.

> - 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…

Not unconditionally, no. The script is a bit more complex, have a look
at it on an old release (/etc/init.d/boot.cleanup).

> 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.

Ah, ‘D’. I did not notice that one.

> 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.
>

In the old system, you can easily choose a preferred running time, and
if that hour is not available because of hibernation for several days in
a row, it will then run after a defined number of days of not running.

And the configuration is done on a central place, not scattered around
on several places, and you do not need to read manuals, as the comments
in the files explain it all.

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

It is not “just use it”. I have to copy it back from another release,
and verify that it doesn’t break anything else, changing things.

–
Cheers / Saludos,

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

[wolfi323]

@robin_listas

On 2014-08-15 20:56, wolfi323 wrote:
>
> robin_listas;2659399 Wrote:
>>> 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.

Yes, same as me.

Again, no.
You are talking about run-crons, which is part of cron, an (open)SUSE extension to cron that calls the scripts in /etc/cron.xxx.
I was talking about the actual script that cleans tmp.

There is a difference.
The script I am talking about doesn’t take care about when it is run and by whom it is run at all. cron calls it (via its run-crons script) and decides when it is being called.
That was my point.

Yes, that is so.
There is an alternative cron daemon which does, though: anacron.

Yes.
And there might be other ones as well.

I prefer the suse implementation of cron scripts. In my scenario above
of hibernation, it would still run at my preferred hour range, but
another day. With systemd, the actual time of running delays for several
days, even weeks.

Except if you change the timer (or create your own timer) to an OnCalendar event.

Well, if we want to write/insert a deletion job, we have to know where
and how to do it…

Well, for boot time (as the subject says), it’s easy. Use some sysvinit script or systemd unit…
Nothing much to do with cron or systemd.timer.
For tmp.conf you could also just set ‘D’ instead of ‘d’, this should empty the directory according to the documentation.

[wolfi323]

@robin_listas

On 2014-08-15 21:36, wolfi323 wrote:
>
> robin_listas;2659390 Wrote:
>> 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.

The tmp cleaning that is activated by run-crons.

And its configuration options are available for the systemd way as well, mostly, as explained.

> - 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…

Not unconditionally, no. The script is a bit more complex, have a look
at it on an old release (/etc/init.d/boot.cleanup).

Ok, that’s something different then. Not at all related to cron or the cron job. (I suspected that)
I cannot look at that file at the moment, but the documentation in /etc/sysconfig/cron clearly states that it is unconditionally:

## Type:        string
#
# "Set this to "yes" to entirely remove (rm -rf) all  files and subdirectories
# from the temporary directories defined in TMP_DIRS_TO_CLEAR on bootup.
# Please note, that this feature ignores OWNER_TO_KEEP_IN_TMP - all files will
# be removed without exception."
#
# If this is set to a list of directories (i.e. starts with a "/"), these
# directories will be cleared instead of those listed in TMP_DIRS_TO_CLEAR.
# This can be used to clear directories at boot as well as clearing unused
# files out of other directories.
#
# Defaults to 'no' if unset
#
CLEAR_TMP_DIRS_AT_BOOTUP=""

In the old system, you can easily choose a preferred running time, and
if that hour is not available because of hibernation for several days in
a row, it will then run after a defined number of days of not running.

Again, that’s cron/run-crons, not the cleaning script.

And the configuration is done on a central place, not scattered around
on several places, and you do not need to read manuals, as the comments
in the files explain it all.

I agree.
Although for simple periodic cleaning, /usr/lib/tmpfiles.d/tmp.conf should be easy enough to comprehend either, and is a central place to configure it.

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

It is not “just use it”. I have to copy it back from another release,
and verify that it doesn’t break anything else, changing things.

I already posted that cleaning script.
It is quite simple.

The rest is about cron/run-crons which is still shipped with openSUSE and even installed by default.
And you can configure it in /etc/sysconfig/cron (f.e. the time when it is run) like ever before.

[robin_listas]

On 2014-08-16 16:26, wolfi323 wrote:
>
> robin_listas;2659561 Wrote:
>> On 2014-08-15 20:56, wolfi323 wrote:
>>>
>>> robin_listas;2659399 Wrote:
>>>>> 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.
>>
>> Yes, same as me.
>>
> Again, no.
> You are talking about run-crons, which is part of cron, an (open)SUSE
> extension to cron that calls the scripts in /etc/cron.xxx.

run-crons is a cron job, not strictly part of cron. It is copyrighted by
SuSE, not part of upstream cron (cronie, actually).

It runs scripts found in cron.daily, cron.hourly, cron.monthly, and
cron.weekly (not in cron.d), when it decides.

> I was talking about the actual script that cleans tmp.

Yes, and me too. I’m talking of the whole setup.

> There is a difference.

Yes, of course.

> The script I am talking about doesn’t take care about when it is run and
> by whom it is run at all. cron calls it (via its run-crons script) and
> decides when it is being called.
> That was my point.

Well, mine is that cron does not actually call it, but that it is called
by a cron job script

Very similar, actually, just different words.

> For tmp.conf you could also just set ‘D’ instead of ‘d’, this should
> empty the directory according to the documentation.

And probably safer, as it should know about not deleting systemd
temporary files that already exist at that moment.

–
Cheers / Saludos,

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

[robin_listas]

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

>> Not unconditionally, no. The script is a bit more complex, have a look
>> at it on an old release (/etc/init.d/boot.cleanup).

> Ok, that’s something different then. Not at all related to cron or the
> cron job. (I suspected that)

Well, it is configured in “/etc/sysconfig/cron”, but it is not done by cron - that would be too late, there are services already running. Done by a boot.script it happens before any service.

> I cannot look at that file at the moment, but the documentation in
> /etc/sysconfig/cron clearly states that it is unconditionally:

It is longish - this is the one from 11.4, which I believe it is the last pure systemv release:

#! /bin/sh
#
# Copyright (c) 2001-2005 SuSE Linux AG, Nuernberg, Germany.
# All rights reserved.
#
# /etc/init.d/boot.cleanup
#
### BEGIN INIT INFO
# Provides:          boot.cleanup
# Required-Start:    boot.rootfsck
# Should-Start:      $local_fs boot.quota
# Required-Stop:     $null
# Should-Stop:       $null
# Default-Start:     B
# Default-Stop:
# Short-Description: do cleanup
# Description: Cleanup left over tempfiles from
#       last run: screen sockets, temporary rpm-database files,
#       ssh agent infos, various lockfiles, utmp and some more.
### END INIT INFO

.. /etc/rc.status
.. /etc/sysconfig/cron

rc_reset

case "$1" in
start|stop|restart)
if test "$1" = "start" -o "$RUNLEVEL" = "6" ; then
#
# clean up
#
rm -f /var/lib/rpm/__db*
rm -rf /tmp/screens /tmp/uscreens /var/run/screens /var/run/uscreens 2>/dev/null
rm -f /tmp/.X*lock /var/spool/uucp/LCK* /var/log/sa/sadc.LOCK /fsck_corrected_errors 2>/dev/null
if test -x /usr/bin/find -a -x /usr/bin/xargs; then
{
find /tmp/ssh-* /tmp/gpg-* -type s -name "*agent*" -maxdepth 1 -print0
find /var/run /var/lock -type f ! -wholename /var/run/utmp -print0
if test -d /var/lib/ntp/var/run; then
find /var/lib/ntp/var/run -type f -print0
fi
} 2>/dev/null | xargs -0r rm -f
else
# fallback for find if we get /usr from nfs
rec_rem() {
for f in "$1"/*
do
test "$f" = /var/run/utmp && continue
test -L "$f" && continue
test -f "$f" && rm -f "$f"
test -d "$f" && rec_rem "$f"
done
}
#
test -d /var/run && rec_rem /var/run
test -d /var/lock && rec_rem /var/lock
fi
touch /var/run/utmp
chmod 664 /var/run/utmp
chown root:utmp /var/run/utmp

# Re-read inittab for jobs and redo utmp records if required
test "$PREVLEVEL" = "S" && telinit q

#       FASTBOOT: This costs us ~1s, and could be done by a simple "mv"
#       if at all necessary.
#
#       # Restore a possibly dynamically modified /etc/resolv.conf
test "$DO_FASTBOOT" != "yes" && /sbin/netconfig update

# delete temp files
# If $CLEAR_TMP_DIRS_AT_BOOTUP = yes, delete files in
# $TMP_DIRS_TO_CLEAR, if $CLEAR_TMP_DIRS_AT_BOOTUP starts with a "/"
# delete files in those dirs instead.
CLEAR_DIRS="$TMP_DIRS_TO_CLEAR"
if  "${CLEAR_TMP_DIRS_AT_BOOTUP:0:1}" = "/" ]; then
CLEAR_DIRS="$CLEAR_TMP_DIRS_AT_BOOTUP"
CLEAR_TMP_DIRS_AT_BOOTUP=yes
fi
if test -x /usr/bin/find -a -x /usr/bin/xargs ; then
if test "$CLEAR_TMP_DIRS_AT_BOOTUP" = yes; then
echo -n "Cleaning temporary directories $CLEAR_DIRS"
find $CLEAR_DIRS -mindepth 1 -maxdepth 1 -print0 2>/dev/null | xargs -0r rm -rf
rc_status -v -r
fi
fi
for script in /etc/tmpdirs.d/* ; do
test -f $script && builtin . $script
done
fi
;;
status)
# assume we have been run
rc_reset
rc_status -v
;;
*)
echo "Usage: $0 {start|stop|status|restart}"
exit 1
;;
esac

rc_exit

It can not be used as is, as it has references to inittab, telinit, fastboot…

>> In the old system, you can easily choose a preferred running time, and
>> if that hour is not available because of hibernation for several days in
>> a row, it will then run after a defined number of days of not running.
> Again, that’s cron/run-crons, not the cleaning script.

So?

It is that what decides when the cleaning script runs.

–
Cheers / Saludos,

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

[wolfi323]

@robin_listas

run-crons is a cron job, not strictly part of cron. It is copyrighted by
SuSE, not part of upstream cron (cronie, actually).

It runs scripts found in cron.daily, cron.hourly, cron.monthly, and
cron.weekly (not in cron.d), when it decides.

Sigh. That’s why I called it “an (open)SUSE extension to cron that calls the scripts in /etc/cron.xxx”
But it is part of openSUSE’s cron package (cronie actually), and it is still there in 13.1.

Ok, it doesn’t call things in cron.d, sorry for not explicitely stating that, but I didn’t find it relevant here.

> I was talking about the actual script that cleans tmp.

Yes, and me too. I’m talking of the whole setup.

But the whole setup is not just the suse.de-clean-tmp script alone. It includes run-crons for you.
So we were not talking about the same thing.

> There is a difference.

Yes, of course.

Why are you insisting then that we were talking about the same?

> The script I am talking about doesn’t take care about when it is run and
> by whom it is run at all. cron calls it (via its run-crons script) and
> decides when it is being called.
> That was my point.

Well, mine is that cron does not actually call it, but that it is called
by a cron job script

Still, run-crons has absolutely nothing to do with actually cleaning /tmp.
It’s just a means to call daily scripts.

Very similar, actually, just different words.

No, IMHO this is completely different.
Again, run-crons is part of openSUSE’s cron package, and is a general way to call daily/weekly/hourly cron jobs.
Whereas suse.de-clean-tmp is just one of several cron jobs, that was there to clean the tmp dirs, and is missing in 13.1.

> For tmp.conf you could also just set ‘D’ instead of ‘d’, this should
> empty the directory according to the documentation.

And probably safer, as it should know about not deleting systemd
temporary files that already exist at that moment.

Probably, and it would also take other configurations in /usr/lib/tmpfiles.d/ (or /etc/tmpfiles.d/) into account.
But I haven’t tried it yet.

[wolfi323]

@robin_listas

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

>> Not unconditionally, no. The script is a bit more complex, have a look
>> at it on an old release (/etc/init.d/boot.cleanup).

> Ok, that’s something different then. Not at all related to cron or the
> cron job. (I suspected that)

Well, it is configured in “/etc/sysconfig/cron”, but it is not done by cron - that would be too late, there are services already running. Done by a boot.script it happens before any service.

Yes, I thought that.
You could of course also copy over that init script, or create a systemd unit that does the same.

> I cannot look at that file at the moment, but the documentation in
> /etc/sysconfig/cron clearly states that it is unconditionally:

It is longish - this is the one from 11.4, which I believe it is the last pure systemv release:

Well, have you looked at that script?
If CLEAR_TMP_DIRS_AT_BOOTUP=“yes” it does just a “rm -rf” in the appropriate directories.
It does clean some other stuff as well though, but I suppose this is irrelevant now (haven’t checked in detail).

Btw, I had a look just now, and 11.4 contained the same comment that I quoted.

>> In the old system, you can easily choose a preferred running time, and
>> if that hour is not available because of hibernation for several days in
>> a row, it will then run after a defined number of days of not running.
> Again, that’s cron/run-crons, not the cleaning script.

So?

It is that what decides when the cleaning script runs.

Yes, but that is still included in openSUSE 13.1, as it is part of the cron package.

It’s only the (small) cleaning script that’s setup as daily cron job that is missing.

[robin_listas]

On 2014-08-17 13:36, wolfi323 wrote:
>
> robin_listas;2659594 Wrote:

>>> I was talking about the actual script that cleans tmp.
>>
>> Yes, and me too. I’m talking of the whole setup.
> But the whole setup is not just the suse.de-clean-tmp script alone. It
> includes run-crons for you.

Of course, it is a necesary part for understanding how the
suse.de-clean-tmp works.

> So we were not talking about the same thing.

The “whole setup” includes the suse.de-clean-tmp script

>>> There is a difference.
>>
>> Yes, of course.
> Why are you insisting then that we were talking about the same?

Because IMO, we are.

> Still, run-crons has absolutely nothing to do with actually cleaning
> /tmp.
> It’s just a means to call daily scripts.

Yes.

>> Very similar, actually, just different words.
> No, IMHO this is completely different.
> Again, run-crons is part of openSUSE’s cron package, and is a general
> way to call daily/weekly/hourly cron jobs.
> Whereas suse.de-clean-tmp is just one of several cron jobs, that was
> there to clean the tmp dirs, and is missing in 13.1.

Yes, yes, yes.

But for doing things like choosing when you delete tmp files, you have,
or rather had, to do adjustments to run-crons settings.

You have to take into account the whole thing. Not just cron settings,
not just clean-tmp settings.

–
Cheers / Saludos,

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

[wolfi323]

@robin_listas

But for doing things like choosing when you delete tmp files, you have,
or rather had, to do adjustments to run-crons settings.

The run-crons settings are still there and used, like run-crons is.
And for choosing when to delete tmp files you only had to do adjustments to run-crons’ settings in /etc/sysconfig/cron.

They apply for all daily cronjobs though, not just suse.de-clean-tmp.
It’s totally independant of suse.de-clean-tmp, other than that it calls it once a day, if suse.de-clean-tmp is located in /etc/cron.daily/.

Again, suse.de-clean-tmp is just a simple script that deletes files in some directories (according to some variables in /etc/sysconfig/cron, like TMP_DIRS_TO_CLEAR to specify which directories it should actually clean).
That script has absolutely no influence on when it is being called.
And it’s only that script that is missing in 13.1.
So I don’t get your point at all.

[robin_listas]

On 2014-08-17 13:56, wolfi323 wrote:
>
> robin_listas;2659597 Wrote:

>> It is longish - this is the one from 11.4, which I believe it is the
>> last pure systemv release:
>>
> Well, have you looked at that script?

Yep. But not in all details.

> If CLEAR_TMP_DIRS_AT_BOOTUP=“yes” it does just a “rm -rf” in the
> appropriate directories.

Not “just”

First it does this, all times:

{
find /tmp/ssh-* /tmp/gpg-* -type s -name "*agent*" -maxdepth 1 -print0
find /var/run /var/lock -type f ! -wholename /var/run/utmp -print0
if test -d /var/lib/ntp/var/run; then
find /var/lib/ntp/var/run -type f -print0
fi
} 2>/dev/null | xargs -0r rm -f

That is, it uses ‘find’ to find some files, then call ‘rm -f’ on them, on all boots.

After that, if clear on boot is true, it does the second part:

find $CLEAR_DIRS -mindepth 1 -maxdepth 1 -print0 2>/dev/null | xargs -0r rm -rf

which yes, does remove everything. I was confused by the first part and did not see the second one.

Part of the first section is not needed currently, because “/var/run/” is now a tmpfs.

> It does clean some other stuff as well though, but I suppose this is
> irrelevant now (haven’t checked in detail).

The part about “/tmp/ssh-* /tmp/gpg-*” is interesting. This is not done now, might have side effects.
Or maybe those two programs are using some other place, because I don’t see any such directories on my system.

> It’s only the (small) cleaning script that’s setup as daily cron job
> that is missing.

Yes.

–
Cheers / Saludos,

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

[robin_listas]

On 2014-08-17 14:56, wolfi323 wrote:
>
> robin_listas;2659767 Wrote:
>> But for doing things like choosing when you delete tmp files, you have,
>> or rather had, to do adjustments to run-crons settings.
> The run-crons settings are still there and used, like run-crons is.

yes.

> And for choosing when to delete tmp files you only had to do
> adjustments to run-crons’ settings in /etc/sysconfig/cron.

yes.

> They apply for all daily cronjobs though, not just suse.de-clean-tmp.
> It’s totally independant of suse.de-clean-tmp, other than that it calls
> it once a day, if suse.de-clean-tmp is located in /etc/cron.daily/.

Yes.

> Again, suse.de-clean-tmp is just a simple script that deletes files in
> some directories (according to some variables in /etc/sysconfig/cron,
> like TMP_DIRS_TO_CLEAR to specify which directories it should actually
> clean).

yes.

> That script has absolutely no influence on when it is being called.

Yes!

> And it’s only that script that is missing in 13.1.

Yes.

> So I don’t get your point at all.

Well, you just did

–
Cheers / Saludos,

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

[wolfi323]

@robin_listas

> It does clean some other stuff as well though, but I suppose this is
> irrelevant now (haven’t checked in detail).
The part about “/tmp/ssh-* /tmp/gpg-*” is interesting. This is not done now, might have side effects.
Or maybe those two programs are using some other place, because I don’t see any such directories on my system.

But that is totally irrelevant, if it is doing a “rm -rf” in /tmp afterwards anyway.

I think this is only done explicitely because by default OWNER_TO_KEEP_IN_TMP=“root” is set, and those directories might be owned by root.
So they won’t get cleaned at all if CLEAR_TMP_DIRS_AT_BOOTUP=“no” is set (which is also the default).

Or, to put it in a different way, this part is there to clean /tmp/ssh-* and /tmp/gpg-* in any case, even with the default configuration.
Those contain only sockets though, so they don’t actually take any disk space (or not much anyway). And they would be cleaned with the tmp.conf way as well.

@robin_listas

> So I don’t get your point at all.

Well, you just did

Did I?
But I still don’t see a problem with just putting the old suse.de-clean-tmp script to /etc/cron.daily/.

To explicitely state my point again:
If run-crons (which is still part of openSUSE 13.1) behaves the same, and you put the same suse.de-clean-tmp script into /etc/cron.daily, and have the same configuration in /etc/sysconfig/cron, the whole tmpfile cleaning should behave exactly the same.
I don’t think there were decisive changes to run-crons recently, the last “Changes” comment in the file itself is from “2001-09-13”.
And I just ran “diff” over the one from 11.4 and the one from 13.1, they are indeed exactly the same.

[robin_listas]

On 2014-08-17 15:46, wolfi323 wrote:
>
> robin_listas;2659772 Wrote:
>>
>>> It does clean some other stuff as well though, but I suppose this is
>>> irrelevant now (haven’t checked in detail).
>> The part about “/tmp/ssh-* /tmp/gpg-*” is interesting. This is not done
>> now, might have side effects.
>> Or maybe those two programs are using some other place, because I don’t
>> see any such directories on my system.
> But that is totally irrelevant, if it is doing a “rm -rf” in /tmp
> afterwards anyway.

No, no.

That part is done for everybody, despite setting to delete at boot or not.

> I think this is only done explicitely because by default
> OWNER_TO_KEEP_IN_TMP=“root” is set, and those directories might be owned
> by root.
> So they won’t get cleaned at all if CLEAR_TMP_DIRS_AT_BOOTUP=“no” is set
> (which is also the default).
>
> Or, to put it in a different way, this part is there to clean /tmp/ssh-*
> and /tmp/gpg-* in any case, even with the default configuration.

Exactly.

> Those contain only sockets though, so they don’t actually take any disk
> space (or not much anyway). And they would be cleaned with the tmp.conf
> way as well.

I think they may be now in one of the tmpfs available, so actively
deleting them is not necessary.

> robin_listas;2659778 Wrote:
>>> So I don’t get your point at all.
>>
>> Well, you just did
> Did I?
> But I still don’t see a problem with just putting the old
> suse.de-clean-tmp script to /etc/cron.daily/.

I have to look at that carefully. For instance, any thing in
“/tmp/systemd-private-*” must be skipped.

> To explicitely state my point again:
> If run-crons (which is still part of openSUSE 13.1) behaves the same,
> and you put the same suse.de-clean-tmp script into /etc/cron.daily, and
> have the same configuration in /etc/sysconfig/cron, the whole tmpfile
> cleaning should behave exactly the same.

Yes.

> I don’t think there were decisive changes to run-crons recently, the
> last “Changes” comment in the file itself is from “2001-09-13”.
> And I just ran “diff” over the one from 11.4 and the one from 13.1, they
> are indeed exactly the same.

Yes.

–
Cheers / Saludos,

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

[wolfi323]

@robin_listas

On 2014-08-17 15:46, wolfi323 wrote:
>> But that is totally irrelevant, if it is doing a “rm -rf” in /tmp
> afterwards anyway.

No, no.

That part is done for everybody, despite setting to delete at boot or not.

Yes. But it is totally irrelevant if CLEAR_TMP_DIRS_AT_BOOTUP is set to “yes”.

> Those contain only sockets though, so they don’t actually take any disk
> space (or not much anyway). And they would be cleaned with the tmp.conf
> way as well.

I think they may be now in one of the tmpfs available, so actively
deleting them is not necessary.

No.
I do have 3 of either flavor in /tmp at this moment, two of them dating back to June and July (the third one is from yesterday, I didn’t reboot the system since then).
So, it seems they should be cleaned automatically (by the corresponding programs themselves I suppose), but sometimes this doesn’t happen for whatever reason.
But as I said, they only contain sockets, so shouldn’t impact your free disk space.
And the directories have unique names on each boot, so left-overs from earlier boots shouldn’t cause any misbehavior (if they did it would be a general openSUSE problem nowadays, as that init script doesn’t exist any more, and cleaning /tmp is not enabled by default).

And that cleaning would not being done at all when you only hibernate, which was the actual starting point of this discussion.

You could of course just put that line into /etc/init.d/boot.local or (probably safer) just delete them unconditionally in /etc/init.d/halt.local.
Those scripts are still called by systemd, via boot-local.service and halt-local.service respectively.
OTOH, they should be periodically cleaned by the suse.de-tmp-clean cronjob anyway (unless they are owned by root of course; those I have here on my system now are owned by me though).

> robin_listas;2659778 Wrote:
>>> So I don’t get your point at all.
>>
>> Well, you just did
> Did I?
> But I still don’t see a problem with just putting the old
> suse.de-clean-tmp script to /etc/cron.daily/.

I have to look at that carefully. For instance, any thing in
“/tmp/systemd-private-*” must be skipped.

Ok, but this is totally independent of run-crons or when the script is run again, now.
And it is unrelated to the fact that the script is not included any more.

The script does of course not respect them, as it is from pre-systemd times.
It also does not (and never did) take into account other files in /tmp that might be harmful to just delete.

I think that’s why the OWNER_TO_KEEP_IN_TMP option exists and is set to “root” by default.
I would also think those systemd-private directories are owned by root in fact but I cannot check right now as I don’t have any on my system at the moment. (yes, this is 13.1 with systemd running)

But this problem did exist before systemd was introduced (although there were no /tmp/systemd-private-* directories then of course). It is a inherent problem with that script itself.
It might be (one of) the reason(s) why this script has been removed, and was not enabled by default anyway.