#3631 PR `merged`: NETFS/tar: robust error reporting when backup subshell is signal-killed¶

Labels: enhancement, fixed / solved / done

gdha opened issue at 2026-08-31 13:12:¶

Relax-and-Recover (ReaR) Pull Request Template¶

Please fill in the following items before submitting a Pull Request

Type of Change¶

☐ Bug fix (non-breaking change which fixes an issue)
☒ Bug fix / robustness improvement (non-breaking change which fixes an issue)
☐ New feature (non-breaking change which adds functionality)
☐ This change requires a documentation update

Pull Request (PR) description¶

The NETFS tar backup reporting code (run after wait $BackupPID in
backup/NETFS/default/500_make_backup.sh) unconditionally reads
$FAILING_BACKUP_PROG_FILE and $FAILING_BACKUP_PROG_RC_FILE whenever
backup_prog_rc != 0:

  prog="$(cat $FAILING_BACKUP_PROG_FILE)"
  ...
  rc=$(cat $FAILING_BACKUP_PROG_RC_FILE)

Those two files are written only inside the backup subshell, in the
PIPESTATUS-processing loop. If the subshell (or its tar/dd/... children)
is terminated by a signal before that loop runs — e.g. the whole rear
process tree receives SIGTERM from a timeout, the OOM killer, or a
session/scope teardown — the files are never created. wait then reports
backup_prog_rc = 128 + signal, and reporting emits:

  cat: /var/tmp/rear.XXXX/tmp/failing_backup_prog: No such file or directory
  cat: /var/tmp/rear.XXXX/tmp/failing_backup_prog_rc: No such file or directory
  ERROR:  failed with return code  and below output:
    ---snip---

    ----------

i.e. an empty program name and an empty return code, so all diagnostic
information about why the backup ended is lost. This makes real-world
incidents (backup killed at a fixed elapsed time, target/pipe dropping,
external job reaper) very hard to diagnose.

This PR makes the reporting path robust:

Read FAILING_BACKUP_PROG_FILE / FAILING_BACKUP_PROG_RC_FILE only when
they exist and are non-empty (-s); otherwise fall back to
basename "$BACKUP_PROG" and the known $backup_prog_rc from wait.
This removes the cat: ... No such file or directory messages and the
empty program name / return code in the error output.

Add an explicit elif (( backup_prog_rc > 128 )) branch that decodes the
signal (128 + N) and reports it, e.g.:

ERROR: tar was terminated by signal 15 (SIGTERM), exit code 143.
The archiving process was killed before it could record which pipe
component failed. ...

The change is confined to the (tar) reporting case branch and does not
alter behaviour for the normal success path, the rc == 1 "files changed"
warning, or the ordinary non-zero return code error path.

Related to #1913 (NETFS+tar can report a wrong/empty exit code and lose the
real failure reason).

How was this PR tested?¶

Distribution/version(s): Fedora/RHEL family (reproduced originally on
rear-2.6-28.el9); fix developed against current master.
bash -n usr/share/rear/backup/NETFS/default/500_make_backup.sh → passes.
Verified against a real incident log where rear mkbackup (BACKUP=NETFS,
tar → dd → NFS) was killed with exit code 143 (SIGTERM). Before the change
the log showed the two cat: ... No such file or directory lines and
ERROR: failed with return code and below output: (blank prog and rc).
With the change, the reporting no longer references the missing files and
instead reports the terminating signal and exit code.

Checklist¶

☒ My code follows the style guidelines of this project
☒ I have performed a self-review of my own code
☒ I have commented my code, particularly in hard-to-understand areas
☐ I have made corresponding changes to the documentation
☐ My changes generate no new warnings
☒ I ran bash -n on the changed script and it reports no syntax errors

A few notes:

Title suggestion (≤70 chars): NETFS/tar: robust error reporting when backup subshell is signal-killed
I kept the "requires documentation update" and "corresponding changes to the documentation" boxes unchecked — this is a diagnostics-only behavior fix, no doc changes needed.

codacy-production commented at 2026-08-31 13:13:¶

Up to standards ✅¶

🟢 Issues 0 issues

>
> > **Results:** > `0` new issues > > [View in > Codacy](https://app.codacy.com/gh/rear/rear/pull-requests/3631/issues) >

_{NEW Get contextual insights on your PRs based on Codacy's
metrics, along with PR and Jira context, without leaving GitHub. Enable
AI
reviewer}
_{TIP This summary will be updated as you push new changes.}

jsmeix commented at 2026-09-01 07:53:¶

@gdha
thank you for this enhancement.

Yes - sigh! - signals are an error handling problem
because actually one would have to implement
additional signal (error) handling everywhere
as signals can appear everywhere at any time.

Perhaps we should implement generic signal handling
by using trap on all (trappable) signals and output
a message on the user's terminal and in the log file
that tells which signal there is?

I made a pull request for generic signal reporting:
https://github.com/rear/rear/pull/3634

jsmeix commented at 2026-09-09 11:45:¶

@rear/contributors
I would like to merge it on Friday (11. Sept.) afternoon
unless there are objections.
Please have a look (as time permits).

[Export of Github issue for rear/rear.]

#3631 PR merged: NETFS/tar: robust error reporting when backup subshell is signal-killed¶