#2403 Issue closed: ReaR doesn't remove /tmp/rear.* directory/files

Labels: support / question, fixed / solved / done

bobbysch opened issue at 2020-05-21 19:14:

Relax-and-Recover (ReaR) Issue Template

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

  • ReaR version ("/usr/sbin/rear -V"):rear-2.4-11.el7.x86_64

  • OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"):CentOS Linux release 7.7.1908

  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):

OUTPUT=ISO
OUTPUT_URL=nfs://172.16.108.71/nfs_export
BACKUP=NETFS
BACKUP_URL=nfs://172.16.108.71/nfs_export
BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" '/media' '/var/tmp' '/var/crash' '/tmp/rear.*')
NETFS_KEEP_OLD_BACKUP_COPY=

  • Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):Intel NUC

  • System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):x64

  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):UEFI

  • Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):NVMe

  • Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT" or "lsblk" as makeshift):

NAME                        KNAME     PKNAME    TRAN   TYPE FSTYPE     SIZE MOUNTPOINT
/dev/sda                    /dev/sda            sata   disk          256.2G
|-/dev/sda1                 /dev/sda1 /dev/sda         part vfat       200M /boot/efi
|-/dev/sda2                 /dev/sda2 /dev/sda         part xfs          1G /boot
`-/dev/sda3                 /dev/sda3 /dev/sda         part LVM2_mem   255G
  |-/dev/mapper/centos-root /dev/dm-0 /dev/sda3        lvm  xfs         50G /
  |-/dev/mapper/centos-swap /dev/dm-1 /dev/sda3        lvm  swap       7.8G [SWAP]
  `-/dev/mapper/centos-home /dev/dm-2 /dev/sda3        lvm  xfs      197.2G /home
  • Description of the issue (ideally so that others can reproduce it):
    ReaR never removes by itself temp folder and its content after successful backup.
Exiting rear mkbackup (PID 8392) and its descendant processes
Running exit tasks
You should also rm -Rf /tmp/rear.eh4lvdCjfVEOU5A

  • Workaround, if any:

  • Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):

pcahyna commented at 2020-05-21 19:25:

ReaR never removes by itself temp folder and its content after successful backup.

Are you sure that it never removes them? I changed the behavior in PR #2218 and this change is present in rear-2.4-11.el7. See https://bugzilla.redhat.com/show_bug.cgi?id=1693608 .
What should happen is that ReaR preserves those directories when run interactively (from a terminal) and does not preserve them when run non-interactively (like from cron).

https://github.com/rear/rear/pull/2218/files#diff-99ed5c4e014ed0e3d2c094ed36c8cfc3R131-R140

gozora commented at 2020-05-21 19:27:

@bobbysch

What is the exact command you are using to launch ReaR?

V.

bobbysch commented at 2020-05-21 19:48:

@gozora:
rear -d -v mkbackup

pcahyna commented at 2020-05-21 19:59:

@gozora good question! @bobbysch see the description of KEEP_BUILD_DIR: "is automatically set to true in debug mode (-d) and in debugscript mode (-D)." ( /usr/share/rear/conf/default.conf )

bobbysch commented at 2020-05-21 20:00:

@pcahyna
I ran it interactively from a terminal.
I also tried after your suggestion to run it using cron, the same behavior still occurs.

gozora commented at 2020-05-21 20:04:

@bobbysch to be on same site.
Can you run rear mkbackup (without -d and -v) and check if /tmp/rear.* is still kept?

V.

bobbysch commented at 2020-05-21 20:06:

Problem solved without -d debugging option (-v option can be used).
Thanks a lot guys for your valuable time and contribution to this great project.

pcahyna commented at 2020-05-21 20:07:

What should happen is that ReaR preserves those directories when run interactively (from a terminal) and does not preserve them when run non-interactively (like from cron).

That was misleading, sorry. It applies only when ReaR encounters an error. When successful, it should not preserve the build directory.

bobbysch commented at 2020-05-21 20:08:

Good job guys! I'm very impressed for the very short answers to my question.

[Export of Github issue for rear/rear.]