#968 Issue closed: default.conf sets TMPDIR to empty value which violates Unix standards

Labels: bug, fixed / solved / done

jsmeix opened issue at 2016-08-17 12:12:

In current rear master code there is in
usr/share/rear/conf/default.conf

TMPDIR=""
export TMPDIR

That violates Unix standards e.g. see
https://en.wikipedia.org/wiki/TMPDIR
where the user can have TMPDIR set to what he likes
and then all Unix standard compliant programs would
store their temporary files (instead of the system default).

But for rear this does not work, see
https://github.com/rear/rear/issues/967#issuecomment-240368699

rear does not honor a specified TMPDIR
instead it overwrites any specified TMPDIR
with an empty value by default.

@gdha
I also assingn you because according to
"git blame -w usr/share/rear/conf/default.conf"
you implemented that.

@gdha
is there a reasoning behind why rear does not work
in compliance with Unix standards regarding TMPDIR?

FYI:
When I comment out that in default.conf as

#TMPDIR=""
#export TMPDIR

then it just works for me as expected:

# unset TMPDIR
# rear -d -D mkrescue

is using build area '/tmp/rear.qT4gIvw0UUXUxnf'
and

# TMPDIR="/var/tmp" rear -d -D mkrescue

is using build area '/var/tmp/rear.gZvwTNixSS7uUyO'

gdha commented at 2016-08-17 12:43:

@jsmeix not really - it was an ugly hack to get duplicity working with rear as /tmp/ had not enough space. I should have read the proper man-pages I know. In rescue.conf the variable itself will be implicitly unset.

jsmeix commented at 2016-08-17 12:57:

@gdha
many thanks for your prompt reply.

For me everything works well when TMPDIR is no longer
set in default.conf.
Then rear behaves in compliance with Unux standards.

And when I set in local.conf e.g.

export TMPDIR="/myreartmp"

(I had created /myreartmp before and I use intentionally a directory
that does not exist on normal systems for my test)
then "rear mkbackup" is using build area '/myreartmp/rear...'
and - as intended - "rear recover" is using build area '/tmp/rear....'

jsmeix commented at 2016-08-17 13:02:

With https://github.com/rear/rear/pull/969 merged
this issue should be fixed.

jsmeix commented at 2016-08-17 13:17:

An addendum regarding "hack to get duplicity working with rear":

I found by "find * | xargs grep -1 'TMPDIR' | less"
those interesting code parts:

In restore/DUPLICITY/default/20_prompt_user_to_start_restore.sh
and in restore/DUPLICITY/default/40_restore_duplicity.sh
there is

export TMPDIR=$TARGET_FS_ROOT

Let's hope nothing after those scripts needs TMPDIR
set to what it was before ;-)

To be on the safe side I would expect code like:

oldTMPDIR="$TMPDIR"
export TMPDIR=$TARGET_FS_ROOT
...
TMPDIR="$oldTMPDIR"

speefak commented at 2021-12-15 00:45:

is it possible to set and remote FS for TMPDIR e.g. sshfs ?

speefak commented at 2021-12-21 18:09:

Does TMPDIR support remote filesystems ? Mounting an sshfs filesystem and mapping TMPDIR onto it causes permission errors creating the main ISO file. Excluding the temporary backup.tar file from /tmp/rear.xx /... will be very usefull for big systemsizes.

Outsourcing the Backupfile while its creation is perhaps possible by mounting an sshfs in /tmp/rear.kdR0eQobzObpXSK/tmp/isofs/backup. I've not tested this.

Or is there any config option which creates the backup.tar directly outside /tmp on remote hosts ?

jsmeix commented at 2021-12-22 08:38:

ReaR implements nothing special for TMPDIR.
It is the usual Linux/Unix TMPDIR behaviour.
If you set TMPDIR to "something" it is you who must have
set up that "something" so that it works for you as needed
both for "rear mkrescue/mkbackup" and for "rear recover".
See its description in default.conf - currently online at
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L44

pcahyna commented at 2021-12-22 09:57:

@speefak I don't think it is a good idea to comment on issues closed a long time ago, unless your comment is directly related to the original issue (like, if the problem has reappeared). Concerning your questions, I don't think that there is an option "which creates the backup.tar directly outside /tmp on remote hosts", but note that in the current development version TMPDIR is /var/tmp instead of /tmp by default ( #2664 and #2654 ), which may alleviate your problem a bit ( /var/tmp usually has more space ). As for using sshfs for TMPDIR, I don't know why that is not working, can you perhaps try NFS instead? You can also tell ReaR to write the ISO image directly to somewhere else (outside /var) instead of storing a copy under /var/lib/rear/output: see https://github.com/rear/rear/issues/2700#issuecomment-948641660 . That should alleviate the space usage of /var a bit, if this helps.
I suspect there might be a way to let xorriso read tar output from a pipe and avoid creating backup.tar.gz on the filesystem entirely, but that would be a bigger change.

[Export of Github issue for rear/rear.]