#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):

$ 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):

BACKUP_PROG_CRYPT_OPTIONS="/usr/bin/openssl des3 -salt -k "
BACKUP_PROG_DECRYPT_OPTIONS="/usr/bin/openssl des3 -d -k "
RESULT_SENDMAIL="$( type -p sendmail || echo /usr/lib/sendmail )"

  • 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:

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

It is caused by


and the code in usr/share/rear/output/default/95_email_result_files.sh

# 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:


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:

I fully agree with what @schlomo wrote in
and in
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:

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

        # 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".

gdha commented at 2017-03-08 12:22:

@jsmeix Was this already done? I cannot recall anymore - memory leak?

jsmeix commented at 2017-03-08 13:50:

it is not yet done.

gdha commented at 2018-03-05 16:59:

@BCITMike Do you still have this problem with the latest release?

BCITMike commented at 2018-03-08 02:30:

Sorry, I'm no longer using rear.

github-actions commented at 2020-07-02 01:33:

Stale issue message

[Export of Github issue for rear/rear.]