#888 Issue `closed`: mkrescue results in "ERROR: No files to send (RESULT_FILES is empty)"¶

Labels: enhancement, documentation, cleanup, no-issue-activity

BCITMike opened issue at 2016-06-21 22:04:¶

rear version (/usr/sbin/rear -V):
Relax-and-Recover 1.18 / Git
OS version (cat /etc/rear/os.conf or lsb_release -a):
OS_VENDOR=RedHatEnterpriseServer
OS_VERSION=7

$ cat /etc/centos-release
CentOS Linux release 7.2.1511 (Core)

rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):
OUTPUT=USB
OUTPUT_URL=usb:///dev/disk/by-label/REAR-000
USB_DEVICE=/dev/disk/by-label/REAR-000

BACKUP=NETFS
BACKUP_PROG=tar
BACKUP_PROG_WARN_PARTIAL_TRANSFER=1
BACKUP_PROG_COMPRESS_OPTIONS="--gzip"
BACKUP_PROG_COMPRESS_SUFFIX=".gz"
BACKUP_PROG_CRYPT_ENABLED=1
BACKUP_PROG_CRYPT_KEY="my_super_Secret_pw"
BACKUP_PROG_CRYPT_OPTIONS="/usr/bin/openssl des3 -salt -k "
BACKUP_PROG_DECRYPT_OPTIONS="/usr/bin/openssl des3 -d -k "
BACKUP_TYPE=incremental
FULLBACKUPDAY="Sun"
BACKUP_URL="nfs://192.168.0.2/volume1/server_backup/rear/"
RESULT_MAILTO=(mike@myemail.com)
RESULT_MAILFROM=root
RESULT_MAILSUBJECT="REAR Job result"
RESULT_SENDMAIL="$( type -p sendmail || echo /usr/lib/sendmail )"
RESULT_SENDMAIL_OPTIONS=( -oi -t )

Brief description of the issue
Trying to create rescue USB key that is directly connected to the server and save backup files to a mounted NFS server (NAS) on the network. The Centos 7 install is using EFI. With a modification to increase partition from 100MB to 200MB (issue #849 ), I am formatting the USB key with the command, which appears to work:
sudo rear format -- --efi /dev/sde

However, when I go to mkrescue, it gets to the end and then fails with:
ERROR: No files to send (RESULT_FILES is empty)

I check the log, and it ends with:

2016-06-21 14:42:21 Including output/USB/Linux-i386/85_make_USB_bootable.sh
/tmp/rear.JPRzh8E2x6YCzvv/outputfs/boot/syslinux is device /dev/sde2
2016-06-21 14:42:41 Writing MBR to /dev/sde
1+0 records in
1+0 records out
440 bytes (440 B) copied, 0.113803 s, 3.9 kB/s
2016-06-21 14:42:41 Including output/default/94_grub2_rescue.sh
2016-06-21 14:42:41 Including output/default/94_grub_rescue.sh
2016-06-21 14:42:41 Including output/default/95_copy_result_files.sh
2016-06-21 14:42:41 Copying resulting files to usb location
'/opt/rear/usr/share/rear/conf/templates/RESULT_usage_USB.txt' -> '/tmp/rear.JPRzh8E2x6YCzvv/outputfs/server/README'
2016-06-21 14:42:41 Saved /opt/rear/var/log/rear/rear-server.log as rear.log
2016-06-21 14:42:41 Including output/default/95_email_result_files.sh
2016-06-21 14:42:41 ERROR: No files to send (RESULT_FILES is empty)
=== Stack trace ===
Trace 0: usr/sbin/rear:410 main
Trace 1: /opt/rear/usr/share/rear/lib/mkrescue-workflow.sh:35 WORKFLOW_mkrescue
Trace 2: /opt/rear/usr/share/rear/lib/framework-functions.sh:85 SourceStage
Trace 3: /opt/rear/usr/share/rear/lib/framework-functions.sh:45 Source
Trace 4: /opt/rear/usr/share/rear/output/default/95_email_result_files.sh:8 source
Trace 5: /opt/rear/usr/share/rear/lib/_input-output-functions.sh:150 StopIfError
Message: No files to send (RESULT_FILES is empty)
===================
2016-06-21 14:42:41 Running exit tasks.
umount: /tmp/rear.JPRzh8E2x6YCzvv/outputfs (/dev/sde2) unmounted
removed directory: '/tmp/rear.JPRzh8E2x6YCzvv/outputfs'
2016-06-21 14:42:45 Finished in 61 seconds
2016-06-21 14:42:45 Removing build area /tmp/rear.JPRzh8E2x6YCzvv
removed directory: '/tmp/rear.JPRzh8E2x6YCzvv'
2016-06-21 14:42:45 End of program reached

I got the same error in 1.17.2 yesterday before trying the latest git.

Any insight into what is causing the error?

Thanks in advance

Attaching log:
rear-server.txt

jsmeix commented at 2016-06-22 07:10:¶

It is caused by

RESULT_MAILTO=(mike@myemail.com)

and the code in usr/share/rear/output/default/95_email_result_files.sh
(excerpt):

# email all files specified in RESULT_FILES to RESULT_MAILTO
#
test -z "$RESULT_MAILTO" && return
[ ${#RESULT_FILES[@]} -gt 0 ]
StopIfError "No files to send (RESULT_FILES is empty)"

See usr/share/rear/conf/default.conf about that.

I never used that myself so that I cannot tell right now
how that is meant to work.

"git blame usr/share/rear/conf/default.conf"
tells that @schlomo wrote this in default.conf
so that probably it is best when @schlomo
has a first look what goes on here - primarily
how RESULT_FILES is meant to work.

BCITMike commented at 2016-06-22 09:38:¶

Thank you for your response. I can confirm that the mkrescue completed successfully after I comment out all those RESULT_* variables. I was under the impression this was going to mail success/fail as any good backup script should do (how is this not a feature already? Or is it just me who prefers to setup something initially and be alerted to problems rather than have to babysit things?). Looking at an example local.conf file, I don't know what the purpose of that feature is, and looks like it has a custom purpose that isn't covered in usage case or work flow pages on http://relax-and-recover.org/.

Many thanks for getting me over this last hurdle.

BCITMike commented at 2016-06-22 09:44:¶

@schlomo

I'd suggest changing this to a WARNING instead of ERROR and not bail out if empty files are reported. I don't think it does proper cleanup when it currently bails out on the ERROR.

gdha commented at 2016-08-03 17:43:¶

@BCITMike I think that @schlomo will not agree with you - see http://sched.co/7oIH

jsmeix commented at 2016-08-04 07:33:¶

@gdha
I fully agree with what @schlomo wrote in
https://linuxconcontainerconeurope2016.sched.org/event/7oIH
and in
http://blog.schlomo.schapiro.org/2015/04/warning-is-waste-of-my-time.html
where the latter links to https://github.com/rear/rear/issues/564

But on the other hand @BCITMike could be right
that when there are no RESULT_FILES
it could be not a sufficient reason to error out.

The primary question here is not whether or not
to show the word 'WARNING' in a message.

The primary question here is whether or not
to error out in output/default/95_email_result_files.sh
when there are no RESULT_FILES.

Because there are other places in the code where
it errors out when there are no RESULT_FILES
(e.g. in output/TSM/default/95_dsmc_save_result_files.sh)
the current behaviour is probably correct.

But as far as I see not all places that deal with RESULT_FILES
error out when there are no RESULT_FILES
(e.g. in output/default/95_copy_result_files.sh)
so that the current behaviour could be not correct.

To answer this question one needs to know
how using RESULT_FILES is meant to work.

gdha commented at 2016-08-04 09:07:¶

@jsmeix We should make sure (and yes that is not yet the case everywhere) that that all output workflows have at least one file in RESULT_FILES. If I find time I will have a look into it, but I have to say I'm very occupied lately so it has to be done in free time (perhaps we have to start with a co-funding project so that I can work on these matters in a paid matter).

jsmeix commented at 2016-08-04 09:19:¶

@gdha
no need for you to to it yourself.
I will implememt that all output workflows
have at least one file in RESULT_FILES
and error out if not.

Except where it is documented
that no RESULT_FILES is o.k. as in
output/default/95_copy_result_files.sh

        # if called as mkbackuponly then we just don't have any result files.
        if test "$RESULT_FILES" ; then

but I probably change that to something like

test "mkbackuponly" = "$WORKFLOW" && return

to skip copying RESULT_FILES in case of mkbackuponly
and otherwise (i.e. when copying RESULT_FILES is a valid task)
then error out if there are no RESULT_FILES.

Probabyl I cannot do that for rear version 1.19 but afterwards
because I need to test it carefully to avoid regressions.
Therefore I set the milestone to "Rear future".