Hide Forgot
Description of problem: If rear fails, for whatever reasons, it leaves behind the temporary files/directories. This can easily fill up the disk space and lead to service interruptions => Therefore severity high. Version-Release number of selected component (if applicable): 2.4 How reproducible: Always Steps to Reproduce: 1. Install rear 2. Make sure rear fails (eg. make sure some binary is included that uses a library, that is not automatically included) 3. Run sudo rear mkrescue -v Actual results: Running mkrescue -v gives you the right hint already: """ You should also rm -Rf /var/tmp/rear.Vow2ZOUr9jUanAG """ While this is perfectly fine when running rear interactively, running it via cron should always clean up the temporary files. Expected results: Rear cron job shouldn't leave behind temporary directories, when not run interactively. Additional info: A probable workaround could be to source the rear config and remove $TMPDIR/rear.*. Eventually check if $TMPDIR is set before; Else TMPDIR => /tmp. Customer case will be attached in a hurry.
Some notes: - this behavior is intentional, ReaR leaves around the build directory for debugging in case of errors. See the upstream issue https://github.com/rear/rear/issues/2121 where a user complained about it and the "solution" was just to inform about it in a comment in the default configuration file. - it should not be the case that daily cron runs will fill the temp directory. The crontab contains /usr/sbin/rear checklayout || /usr/sbin/rear mkrescue so the build directory will be left on first run, but on the subsequent ones checklayout will succeed and further build directories should not be produced, so the used space should not grow without bounds and the damage should be limited (unless the disk layout changes often for some reason). - even given the above, I agree that the current behavior is unfortunate and I submitted PR2218 upstream to not leave the build directory around in noninteractive runs and warn more prominently about it (without the -v flag) in interactive runs.
Pavle, Let's add a new option KEEP_BUILD_DIR_ON_ERRORS. If set to yes, keep build dir on errors even in non interactive mode, which is really useful for troubleshoot. If empty, fill KEEP_BUILD_DIR based on tty. Only KEEP_BUILD_DIR itself could not be enough because it always remove directory or always keep it which is not so useful for troubleshoot. Thank you, DJ
Instead of introducing a new variable KEEP_BUILD_DIR_ON_ERRORS, we plan with upstream to introduce a new possible value for KEEP_BUILD_DIR, KEEP_BUILD_DIR="errors", which will have the same semantics as the proposed KEEP_BUILD_DIR_ON_ERRORS=yes. See https://github.com/rear/rear/pull/2218#issuecomment-526679705
PR merged upstream without modification.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:1153