tmp¶

Labels: discuss / RFC, won't fix / can't fix / obsolete

schlomo opened issue at 2023-05-31 21:06:¶

I noticed that NETFS stores the content of /var/tmp which is IMHO a mistake.

I'm wondering where to add /var/tmp?

to BACKUP_PROG_EXCLUDE
to AUTOEXCLUDE_PATH
to both?

@jsmeix what do you think?

jsmeix commented at 2023-06-01 06:49:¶

@schlomo
is /var/mp a typo in
https://github.com/rear/rear/issues/2999#issue-1735023344
?

What exactly do you mean with 'store'?
Do you mean "NETFS shouldn't backup /var/tmp"
?

In general I think /var/tmp should be included in the backup by default
because according to how I understand what /var/tmp is meant for:

# man file-hierarchy
...
  /var/tmp/
    The place for larger and persistent temporary files.
    In contrast to /tmp/, this directory is usually mounted from a
    persistent physical file system and can thus accept larger files.
    (Use /tmp/ for small ephemeral files.)
    This directory is generally not flushed at boot-up,
    but time-based cleanup of files that have not been accessed
    for a certain time is applied.

Therein the crucial parts related to this issue are for me
"persistent temporary files" and "not flushed at boot-up"
from which I deduce that /var/tmp/ should also by default
persist disaster recovery i.e. not flushed at disaster recovery.

See also what I think what disaster recovery should do
in "Goal: Recreate a destroyed system" in
https://en.opensuse.org/SDB:Disaster_Recovery

... recreate it as much as possible as it was before ...

Only if data in /var/tmp/ can never be useful
after the system was recreated, then /var/tmp
could be excluded from the backup by default.

schlomo commented at 2023-06-01 06:54:¶

So if it gets cleaned time based then we can also skip it in backups to reduce backup size and speed up restores

By definition nobody should expect those files to persist, it must be ok to delete then any time.

Therefore my question: to which variable should i add the directory to excite it from backup?

And yes, I want to minimize the backup by default.

jsmeix commented at 2023-06-01 07:02:¶

No,
when it gets cleaned time based, we cannot skip it in backups
because we have no right to overwrite
the user's time based cleanup procedure.

E.g. when the user wants to keep files in /var/tmp
that have not been accessed for more than one month
and a disaster recovery happens, then after backup restore
all files in /var/tmp that have not been accessed for
less than one month must have been restored by default.
This way on the recreated system the user's time based cleanup
method will continue to behave as it did on his original system.

jsmeix commented at 2023-06-01 07:05:¶

You are free to minimize your backup as you like
but STOP to impose your will on our users!

pcahyna commented at 2023-06-01 09:16:¶

/var/tmp is typically used for editor temporary files (if not saved next to the file being edited). When your machine crashes, you don't want to lose the files you had been editing but had not saved. That's why the recovery files should be kept in a place that does not get cleaned up on boot.

Whether it should be included in the backup is a matter of taste for me. If this is desired, BACKUP_PROG_EXCLUDE is the right place IMO (currently the default value is

BACKUP_PROG_EXCLUDE=( '/tmp/*' '/dev/shm/*' "$VAR_DIR/output/*" )

I hope that in any case, ReaR's temporary directory is not included in the backup (I changed the default location to /var/tmp in #2664)

pcahyna commented at 2023-06-01 09:41:¶

it is not: BACKUP_PROG_EXCLUDE+=( "$BUILD_DIR" ) in usr/sbin/rear

schlomo commented at 2023-06-01 11:36:¶

Thank you @pcahyna, the argument about crash recovery files is really good.

jsmeix commented at 2023-06-02 07:59:¶

Only FYI
as an example how /var/tmp/ looks
on my homeoffice laptop that I use since March 2020
(the time when I started to work in homeoffice)
and I had never cleaned up /var/tmp/ since then:

My /var/tmp/ is only 16 MiB so nothing to worry about.

Therein 15 MiB are many /var/tmp/zypp.* leftover directories, cf.
https://forums.opensuse.org/t/all-versions-there-are-over-500-000-zypp-directories-in-var-tmp-a-fix/141834

The rest are mainly /var/tmp/systemd* directories from only today
(i.e. systemd properly cleans up its stuff in /var/tmp)
so almost nothing is left from other programs in /var/tmp.

In my case an empty /var/tmp/efi_virt/ directory is the only
thing in /var/tmp except /var/tmp/zypp.* and /var/tmp/systemd*

Details:

# du -hs /var/tmp
16M     /var/tmp

# ls -ldt /var/tmp/*
drwx------ 3 root root 4096 Jun  2 08:13 /var/tmp/systemd-private-bd...c6-fwupd.service-0x9BAg
drwx------ 3 root root 4096 Jun  2 08:12 /var/tmp/systemd-private-bd...c6-colord.service-zxFH5f
drwx------ 3 root root 4096 Jun  2 08:12 /var/tmp/systemd-private-bd...c6-rtkit-daemon.service-UD64Qg
drwx------ 3 root root 4096 Jun  2 08:12 /var/tmp/systemd-private-bd...c6-upower.service-XGX4Dg
drwx------ 3 root root 4096 Jun  2 08:12 /var/tmp/systemd-private-bd...c6-power-profiles-daemon.service-IYKYvg
drwx------ 3 root root 4096 Jun  2 08:12 /var/tmp/systemd-private-bd...c6-chronyd.service-qIr6Xe
drwx------ 3 root root 4096 Jun  2 08:11 /var/tmp/systemd-private-bd...c6-ModemManager.service-jfbufi
drwx------ 3 root root 4096 Jun  2 08:11 /var/tmp/systemd-private-bd...c6-systemd-logind.service-MHuppi
drwx------ 3 root root 4096 Jun  2 08:11 /var/tmp/systemd-private-bd...c6-iio-sensor-proxy.service-a8qe6g
drwx------ 4 root root 4096 Apr 19 15:14 /var/tmp/zypp.BoRG4u
drwx------ 4 root root 4096 Feb 21 08:38 /var/tmp/zypp.UD898a
drwx------ 4 root root 4096 Jan 19 16:22 /var/tmp/zypp.pyhUqR
drwxr-xr-x 2 root root 4096 Jan 13 09:52 /var/tmp/efi_virt
drwx------ 4 root root 4096 Jan  2 08:57 /var/tmp/zypp.VlyVC2
drwx------ 5 root root 4096 Jul 27  2022 /var/tmp/zypp.7c1em7
...
[281 more /var/tmp/zypp.* directories]
...
drwx------ 4 root root 4096 Mar 11  2020 /var/tmp/zypp.FJREJZ
drwx------ 4 root root 4096 Mar 11  2020 /var/tmp/zypp.7y5jOT

# du -hsc /var/tmp/zypp*
64K     /var/tmp/zypp.03ibYt
28K     /var/tmp/zypp.0L2cMk
...
[284 more /var/tmp/zypp.* directories]
...
200K    /var/tmp/zypp.YdE4fp
64K     /var/tmp/zypp.YfvnIn
15M     total

# du -hs --exclude='zypp*' /var/tmp
92K     /var/tmp

pcahyna commented at 2023-06-02 09:14:¶

@jsmeix if running ReaR often you could have ReaR leftovers there :-) (ReaR uses /var/tmp by default not because it needs persistence across reboot, but because it needs lots of space. Unfortunately, FHS does not seem to have a place for temporary files intended to have lots of space and at the same time not persistent.)

jsmeix commented at 2023-06-02 10:21:¶

@pcahyna
I think since you reworked how ReaR cleanes up its build area
ReaR behaves perfectly well i.e. it behaves as good as possible,
in particular without blindly removing unintended data by accident.

That there is no place for big non-persistent temporary files
is the root cause of all nowadays mess with temporary files.

See what I had written (meanwhile this part became removed) in
https://en.opensuse.org/index.php?title=openSUSE:Tmp_on_tmpfs&oldid=50818

Consequence

Applications that write huge files to /tmp/ which are
not meant to be preserved between system reboots work
in compliance with the Filesystem Hierarchy Standard
and cannot be "fixed" by using /var/tmp/ instead
because files in /var/tmp/ cannot be cleaned up
automatically when the system is booted.

This conflicts with what is requested regarding
"My CD burning application writes huge .iso files
 to /tmp, and this breaks on tmpfs! - The application
 should be fixed to use /var/tmp."
at Fedora in
https://fedoraproject.org/wiki/Features/tmp-on-tmpfs#Comments_and_Discussion

If /tmp/ is on tmpfs there is the question what the right place is
for arbitrary kind of huge temporary files which are not meant
to be preserved between system reboots?

This question is not properly answered up to now.
Instead postings that ask this question get removed.
I am fed up and finished with any discussions
about "the right handling" of temporary files.
All is lost unless the basic questions get solved.
And this is not something that belongs to ReaR.

Modernized question:
"My application writes huge files to /var/tmp
but when the system crashes (e.g. kernel panic)
those huge files are still there after reboot."

[Export of Github issue for rear/rear.]

#2999 Issue closed: NETFS shouldn't store /var/tmp¶