#3634 PR `merged`: Generic signal reporting¶

Labels: enhancement, fixed / solved / done

jsmeix opened issue at 2026-09-01 13:46:¶

Type: Enhancement
Impact: Low and High

Impact should be low
BUT
trapping so many signals could have
unintended and unexpected bad side effects
so extra care is needed to verify
that those changes do work as intended
for our users in practice "out there".

Reference to related issue (URL):

https://github.com/rear/rear/pull/3631#issuecomment-5490758724
(excerpt)

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?

How was this pull request tested?

Description of the changes in this pull request:

In _framework-setup-and-functions.sh
added generic signal reporting
to notify the user which signal it was
when a signal terminated the ReaR main shell.

The generic signal reporting function
handle_terminating_signal ()
can be used as signal handler at other code places
as needed (in particular in subshells).

codacy-production commented at 2026-09-01 13:47:¶

Up to standards ✅¶

🟢 Issues 0 issues

>
> > **Results:** > `0` new issues > > [View in > Codacy](https://app.codacy.com/gh/rear/rear/pull-requests/3634/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 14:23:¶

@gdha
could you please test it (provided time permits)
in the environment of your
https://github.com/rear/rear/pull/3631

jsmeix commented at 2026-09-02 11:46:¶

A generic problem is that subshells
do not inherit traps of the parent shell
so when a subshell gets a signal as in
https://github.com/rear/rear/pull/3631
that signal will not be reported
by this trap of the ReaR main shell here.

Because bash runs commands within subshells
it means when a command process gets a signal
that signal will not be reported
by this trap of the ReaR main shell here.

This makes it rather questionable
if at least the current implementation of
generic signal reporting by a trap in the main shell
would be sufficiently useful in practice
i.e. that it is worth the risk and effort
and
if perhaps the whole idea of implementing
generic signal reporting does not make sense
and
if perhaps individual signal handling at
each individual place is the only way
which can be done in practice
but
the latter is likely not worth the effort in general
except in specific cases where it is known that
signal handling is actually needed in practice
e.g. as in https://github.com/rear/rear/pull/3631

I make this pull request a "draft" until it is clear
if it makes sense at all to proceed here.

jsmeix commented at 2026-09-03 11:53:¶

Regardless if it will be actually userful or not in ReaR
I will proceed here a bit more and at least fix my current
wrong implementation to something which is at least not wrong
according to what Google Gemini CLI made as documented in my
https://github.com/jsmeix/report_signals

jsmeix commented at 2026-09-04 12:04:¶

Since I completely overhauled my implementation
of generic signal reporting functionality in
https://github.com/rear/rear/pull/3634/changes/7fed34746db528861c827b035239748470f901a5
I think what there is now could be useful in general
because now the generic signal reporting function
handle_terminating_signal ()
can be used as signal handler at other code places as needed.

jsmeix commented at 2026-09-04 12:05:¶

@rear/contributors
please have a look here (as time permits)
and tell me what you think about it.

jsmeix commented at 2026-09-04 12:30:¶

@gdha
as far as I currently understand it your enhancement in
https://github.com/rear/rear/pull/3631
is still needed because its initial comment reads (excerpt)

the subshell (or its tar/dd/... children)
is terminated by a signal

See my comment in this pull request here in
https://github.com/rear/rear/pull/3634/changes
which describes my current understanding
of generic signal reporting:

# Signals are an error handling problem because one would have to implement
# additional signal (error) handling everywhere as signals can appear everywhere at any time.
# The actual problem is that there is no generic way to get a message when a signal is raised
# so in particular when a signal terminates ReaR there is no message about the signal
# which makes it almost impossible for the user to find out why ReaR had terminated,
# cf. https://github.com/rear/rear/pull/3631
# A generic issue is that subshells cannot inherit traps of the parent shell
# so when a subshell gets a signal it cannot be reported by a trap in the main shell.
# Because bash runs programs within subshells it means when a program gets a signal
# (as in https://github.com/rear/rear/pull/3631) that signal cannot be caught by a trap
# neither in the main shell nor in a subshell where the program is called.
# Only the program itself could catch and report the signal it got.
# So all we can do is providing a generic signal reporting function
# that can be used as signal handler at other code places as needed and
# register that function here as signal handler for the ReaR main shell
# to notify the user when the ReaR main shell process (MASTER_PID)
# got a signal that would usually terminate ReaR.

On the other hand
the initial comment
https://github.com/rear/rear/pull/3631
also reads

e.g. the whole rear process tree receives SIGTERM from
a timeout, the OOM killer, or a session/scope teardown

When it is the ReaR main shell process (MASTER_PID)
which gets a termination signal, then the
generic signal reporting functionality
in this pull request should report that signal.

jsmeix commented at 2026-09-07 12:58:¶

How "rear -D mkbackuponly" behaves for me
when I send SIGTERM to the 'tar' process
(excerpts):

# usr/sbin/rear -D mkbackuponly
Relax-and-Recover 2.9 / 2025-01-31
Running rear mkbackuponly (PID 26506 date 2026-09-07 14:37:24)
...
Making backup (using backup method NETFS)
Creating tar archive '/var/tmp/rear.X0jwL9HJX4y7h80/outputfs/localhost/backup.tar.gz'
Preparing archive operation
Archived 62 MiB [avg 10688 KiB/sec] 
Archived 99 MiB [avg 9290 KiB/sec] 
^Z
[1]+  Stopped                 usr/sbin/rear -D mkbackuponly


# pstree -Ap 26506
rear(26506)-+-rear(31494)-+-dd(31521)
            |             `-tar(31520)---gzip(31524)
            `-sleep(31538)


# kill 31520


# fg
usr/sbin/rear -D mkbackuponly
Archived 102 MiB [avg 2184 KiB/sec] 
OK
ERROR: tar failed with return code 143 and below output (last 5 lines):
  ---snip---

  ----------
This means that the archiving process ended prematurely, or did
not even start. As a result it is unlikely you can recover this
system properly. Relax-and-Recover is therefore aborting execution.

Some latest log messages since the last called script 500_make_backup.sh:
  2026-09-07 14:37:29.004292127 Backup exclude list /var/tmp/rear.X0jwL9HJX4y7h80/tmp/backup-exclude.txt
  2026-09-07 14:37:29.007123114   /tmp/*
  2026-09-07 14:37:29.009740109   /dev/shm/*
  2026-09-07 14:37:29.012493801   /root/rear.github.master.jsmeix-signal-reporting/var/lib/rear/output/*
  2026-09-07 14:37:29.015179796   /var/tmp/rear.X0jwL9HJX4y7h80
  2026-09-07 14:37:29.018023656 Creating tar archive '/var/tmp/rear.X0jwL9HJX4y7h80/outputfs/localhost/backup.tar.gz'
  2026-09-07 14:37:29.032236876 tar --warning=no-xdev --sparse --block-number --totals --verbose --no-wildcards-match-slash --one-file-system --ignore-failed-read --anchored --xattrs --xattrs-include=
  '/var/tmp/rear.X0jwL9HJX4y7h80/tmp/backup.log' -> '/var/tmp/rear.X0jwL9HJX4y7h80/outputfs/localhost/backup.log'
Aborting due to an error, check /root/rear.github.master.jsmeix-signal-reporting/var/log/rear/rear-localhost.26506.log for details
Process (PID 26506) got signal 15 (SIGTERM) that is terminating by default
Exiting rear mkbackuponly (PID 26506) and its descendant processes ...
Running exit tasks
To remove the build area you may use (with caution): rm -Rf --one-file-system /var/tmp/rear.X0jwL9HJX4y7h80
Terminated

The message

Process (PID 26506) got signal 15 (SIGTERM) that is terminating by default

where PID 26506 is the ReaR main shell (MASTER_PID)
happens because in our Error() function we do

kill -USR1 $MASTER_PID

and in lib/_framework-setup-and-functions.sh we have

builtin trap "... ; kill $MASTER_PID" USR1

so our Error() function results that MASTER_PID gets SIGTERM
which is now reported by the generic signal reporting
BUT
(as described in my above
https://github.com/rear/rear/pull/3634#issuecomment-5540446763)
the generic signal reporting for MASTER_PID
cannot report that 'tar' got SIGTERM.
In my case 'tar' itself indicated that indirectly
via its exit code 143 = 128 + 15 (15 = SIGTERM)
which in my case gets reported via the message

ERROR: tar failed with return code 143 ...

jsmeix commented at 2026-09-07 13:10:¶

How "rear -D mkbackuponly" behaves for me
when I send SIGTERM to the ReaR main process (MASTER_PID)
(excerpts):

# usr/sbin/rear -D mkbackuponly
Relax-and-Recover 2.9 / 2025-01-31
Running rear mkbackuponly (PID 32364 date 2026-09-07 15:00:00)
...
Making backup (using backup method NETFS)
Creating tar archive '/var/tmp/rear.T7ILmpS7Gk7xzug/outputfs/localhost/backup.tar.gz'
Preparing archive operation
Archived 62 MiB [avg 10688 KiB/sec] 
Archived 99 MiB [avg 9246 KiB/sec] 
^Z
[1]+  Stopped                 usr/sbin/rear -D mkbackuponly


# pstree -Ap 32364
rear(32364)-+-rear(5267)-+-dd(5294)
            |            `-tar(5293)---gzip(5297)
            `-sleep(5311)


# kill 32364

# fg
usr/sbin/rear -D mkbackuponly
Process (PID 32364) got signal 15 (SIGTERM) that is terminating by default
Exiting rear mkbackuponly (PID 32364) and its descendant processes ...
Terminating descendant process 5297 gzip
Running exit tasks
To remove the build area you may use (with caution): rm -Rf --one-file-system /var/tmp/rear.T7ILmpS7Gk7xzug
rear mkbackuponly failed, check /root/rear.github.master.jsmeix-signal-reporting/var/log/rear/rear-localhost.32364.log for details
Terminated

In var/log/rear/rear-localhost.32364.log there is
(excerpts)

2026-09-07 15:00:05.363079466 Making backup (using backup method NETFS)
...
2026-09-07 15:00:05.411681551 Creating tar archive '/var/tmp/rear.T7ILmpS7Gk7xzug/outputfs/localhost/backup.tar.gz'
++ ProgressStart 'Preparing archive operation'
...
++ ProgressInfo 'Archived 62 MiB [avg 10688 KiB/sec] '
...
++ ProgressInfo 'Archived 99 MiB [avg 9246 KiB/sec] '
++ echo 'Archived 99 MiB [avg 9246 KiB/sec] '
++ sleep 5
+++ handle_terminating_signal 15 SIGTERM
...
2026-09-07 15:00:43.580770559 Process (PID 32364) got signal 15 (SIGTERM) that is terminating by default
...
2026-09-07 15:00:43.596747679 Exiting rear mkbackuponly (PID 32364) and its descendant processes ...
...
2026-09-07 15:00:46.769601731 Terminating descendant process 5297 gzip
...
2026-09-07 15:00:47.786656046 Running exit tasks

So as @gdha described in his
https://github.com/rear/rear/pull/3631#issue-5300547855
there is no message about 'tar'
BUT
(as described in my above
https://github.com/rear/rear/pull/3634#issuecomment-5540446763)
the generic signal reporting for MASTER_PID
shows at least that MASTER_PID got SIGTERM.

jsmeix commented at 2026-09-07 13:26:¶

A quick "rear recover" test worked well for me.
I will test it a bit more tomorrow.

jsmeix commented at 2026-09-08 10:21:¶

How "rear -D recover" behaves for me
when I press [Ctrl]+[C] (i.e. send SIGINT)
in the terminal where I run ReaR:
(excerpts):

RESCUE localhost:~ # rear -D recover
Relax-and-Recover 2.9 / 2025-01-31
Running rear recover (PID 814 date 2026-09-08 12:17:19)
...
Disk configuration looks identical
UserInput -I DISK_LAYOUT_PROCEED_RECOVERY needed in /usr/share/rear/layout/prepare/default/250_compare_disks.sh line 235
Proceed with 'recover' (yes) otherwise manual disk layout configuration is enforced
(default 'yes' timeout 30 seconds)
^CProcess (PID 814) got signal 2 (SIGINT) that is terminating by default
Exiting rear recover (PID 814) and its descendant processes ...
Running exit tasks
To remove the build area you may use (with caution): rm -Rf --one-file-system /var/tmp/rear.0pg13PvZJ8h3KI0
rear recover failed, check /var/log/rear/rear-localhost.log for details

jsmeix commented at 2026-09-08 10:27:¶

How "rear -D recover" behaves for me
when I send SIGTERM to the ReaR main process (MASTER_PID)
(excerpts):

RESCUE localhost:~ # rear -D recover
Relax-and-Recover 2.9 / 2025-01-31
Running rear recover (PID 7088 date 2026-09-08 12:25:49)
...
Started RPC portmapper 'rpcbind'.
RPC portmapper 'rpcbind' available.
RPC status rpc.statd available.
^Z
[1]+  Stopped                 rear -D recover


RESCUE localhost:~ # pstree -Ap 7088
rear(7088)---rear(9299)


RESCUE localhost:~ # kill 7088


RESCUE localhost:~ # fg
rear -D recover
Process (PID 7088) got signal 15 (SIGTERM) that is terminating by default
Exiting rear recover (PID 7088) and its descendant processes ...
Running exit tasks
To remove the build area you may use (with caution): rm -Rf --one-file-system /var/tmp/rear.dd0tOdAReLB7OnY
rear recover failed, check /var/log/rear/rear-localhost.log for details
Terminated

jsmeix commented at 2026-09-08 10:56:¶

How "rear -D recover" behaves for me
when I send SIGTERM to a subshell of the ReaR main process
(excerpts):

RESCUE localhost:~ # rear -D recover
Relax-and-Recover 2.9 / 2025-01-31
Running rear recover (PID 9379 date 2026-09-08 12:30:06)
...
UserInput -I DISK_LAYOUT_PROCEED_RECOVERY needed in /usr/share/rear/layout/prepare/default/250_compare_disks.sh line 235
Proceed with 'recover' (yes) otherwise manual disk layout configuration is enforced
(default 'yes' timeout 30 seconds)
^Z
[1]+  Stopped                 rear -D recover


RESCUE localhost:~ # pstree -Aplau 9379
rear,9379 /bin/rear -D recover
  `-rear,12410 /bin/rear -D recover


RESCUE localhost:~ # kill 12410



RESCUE localhost:~ # fg
rear -D recover
User enforced manual disk layout configuration
Using /dev/vda (same name and same size 16106127360) for recreating /dev/vda
...

In /var/log/rear/rear-localhost.log there is
(excerpt):

+++ DebugPrint 'UserInput -I DISK_LAYOUT_PROCEED_RECOVERY needed in /usr/share/rear/layout/prepare/default/250_compare_disks.sh line 235'
2026-09-08 12:31:32.386115182 UserInput -I DISK_LAYOUT_PROCEED_RECOVERY needed in /usr/share/rear/layout/prepare/default/250_compare_disks.sh line 235
+++ test -t 0
+++ read -t 0
+++ test 'Proceed with '\''recover'\'' (yes) otherwise manual disk layout configuration is enforced'
+++ LogUserOutput 'Proceed with '\''recover'\'' (yes) otherwise manual disk layout configuration is enforced'
2026-09-08 12:31:32.388687004 Proceed with 'recover' (yes) otherwise manual disk layout configuration is enforced
+++ test ''
+++ test 'default '\''yes'\'' timeout 30 seconds'
+++ is_true no
+++ case "$1" in
+++ return 1
+++ LogUserOutput '(default '\''yes'\'' timeout 30 seconds)'
2026-09-08 12:31:32.392932284 (default 'yes' timeout 30 seconds)
+++ is_true ''
+++ case "$1" in
+++ return 1
+++ local read_options_and_arguments=
+++ is_true no
+++ case "$1" in
+++ return 1
+++ is_true no
+++ case "$1" in
+++ return 1
+++ test 30 -ge 1
+++ read_options_and_arguments+=' -t 30'
+++ test ''
+++ test 0 -ge 1
+++ test ''
+++ local input_string=
+++ local predefined_input_variable_name=USER_INPUT_DISK_LAYOUT_PROCEED_RECOVERY
+++ test ''
+++ local return_code=0
+++ contains_visible_char ''
++++ tr -d -c '[:graph:]'
+++ test ''
+++ read -t 30 input_string
++ input_value=
++ wilful_input=no
++ is_true ''
++ case "$1" in
++ return 1
++ MIGRATION_MODE=TRUE
++ LogPrint 'User enforced manual disk layout configuration'
2026-09-08 12:31:52.322600235 User enforced manual disk layout configuration

As expected there is no message that the subshell got SIGTERM.

But that SIGTERM causes different behaviour because
the default behaviour is to proceed with 'recover'
without manual disk layout configuration.

As far as I understand it this happens because in
usr/share/rear/layout/prepare/default/250_compare_disks.sh
the matching code part is

    input_value="$( UserInput -I DISK_LAYOUT_PROCEED_RECOVERY -t "$timeout" -p "$prompt" -D 'yes' )" && wilful_input="yes" || wilful_input="no"
    if is_true "$input_value" ; then
        is_true "$wilful_input" && LogPrint "User confirmed to proceed with '$WORKFLOW'" || LogPrint "Proceeding with '$WORKFLOW' by default"
    else
        # The user enforced MIGRATION_MODE uses the special 'TRUE' value in upper case letters
        # that is needed to overrule the prepare/default/270_overrule_migration_mode.sh script:
        MIGRATION_MODE='TRUE'
        LogPrint "User enforced manual disk layout configuration"
    fi

so the subshell is $( UserInput ... ) in

input_value="$( UserInput -I DISK_LAYOUT_PROCEED_RECOVERY -t "$timeout" -p "$prompt" -D 'yes' )"

and SIGTERM to that subshell results that input_value is not true.
This is perfectly right because SIGTERM of that UserInput call
makes it fall back to the safest way how to proceed here
which is manual disk layout configuration.

jsmeix commented at 2026-09-08 11:06:¶

How "rear -D recover" behaves for me
when I send SIGTERM to the restoring 'tar' process
(excerpts up to # fg, after # fg complete output):

# rear -D recover
Relax-and-Recover 2.9 / 2025-01-31
Running rear recover (PID 12807 date 2026-09-08 12:58:51)
...
UserInput -I DISK_LAYOUT_PROCEED_RECOVERY needed in /usr/share/rear/layout/prepare/default/250_compare_disks.sh line 235
Proceed with 'recover' (yes) otherwise manual disk layout configuration is enforced
(default 'yes' timeout 30 seconds)

UserInput: No real user input (empty or only spaces) - using default input
UserInput: No choices - result is 'yes'
User confirmed to proceed with 'recover'
...
Backup restore program 'tar' started in subshell (PID=18166)
Restored 516 MiB [avg. 105875 KiB/sec] 
Restored 1004 MiB [avg. 102837 KiB/sec] 
^Z
[1]+  Stopped                 rear -D recover


RESCUE localhost:~ # pstree -Ap 12807
rear(12807)-+-rear(18166)-+-dd(18176)
            |             `-tar(18177)---tar(18178)---gzip(18179)
            `-sleep(18194)


RESCUE localhost:~ # pstree -Aplau 12807
rear,12807 /bin/rear -D recover
  |-rear,18166 /bin/rear -D recover
  |   |-dd,18176 if=/var/tmp/rear.2eNrGdTqLuiGL7l/outputfs/localhost/backup.tar.gz bs=1M
  |   `-tar,18177 --block-number --totals --verbose --anchored --xattrs --xattrs-include=security.capability --xattrs-include=security.selinux --acls --gzip -C /mnt/local/ -x -f -
  |       `-tar,18178 --block-number --totals --verbose --anchored --xattrs --xattrs-include=security.capability --xattrs-include=security.selinux --acls --gzip -C /mnt/local/ -x -f -
  |           `-gzip,18179 -d
  `-sleep,18194 5


RESCUE localhost:~ # kill 18178


RESCUE localhost:~ # fg
rear -D recover
Restored 1031 MiB [avg. 10258 KiB/sec] 
OK
Backup restore program tar failed with exit code 2, check /var/log/rear/rear-localhost.log and /var/lib/rear/restore/recover.backup.tar.gz.12807.restore.log and the restored system
Restoring finished (verify backup restore log messages in /var/lib/rear/restore/recover.backup.tar.gz.12807.restore.log)
Created SELinux /mnt/local/.autorelabel file : after reboot SELinux will relabel all files
Recreating directories (with permissions) from /var/lib/rear/recovery/directories_permissions_owner_group
Failed to 'chown root:root bin' 
Failed to 'chown root:root dev' 
Failed to 'chown root:root lib' 
Failed to 'chown root:root lib64' 
Failed to 'chown root:root mnt' 
Failed to 'chown root:root proc' 
Failed to 'chown root:root run' 
Failed to 'chown root:root sbin' 
Failed to 'chown root:root sys' 
Failed to 'chown root:root usr/bin' 
Failed to 'chown root:root usr/include' 
Failed to 'chown root:root usr/lib' 
Failed to 'chown root:root usr/lib64' 
Failed to 'chown root:root usr/libexec' 
Failed to 'chown root:root usr/sbin' 
Failed to 'chown root:root usr/src' 
Failed to 'chown root:root var/cache' 
Failed to 'chown root:root var/lib' 
Failed to 'chown root:root var/log' 
Failed to 'chown root:root var/opt' 
Failed to 'chown root:root var/spool' 
Failed to 'chown root:root var/spool/mail' 
Failed to 'chown root:root var/tmp' 
Running 'finalize' stage ======================
Checking if certain restored files are consistent with the recreated system
See /var/lib/rear/layout/config/files.md5sum what files are checked
Restored files in /mnt/local do not fully match the recreated system
(files in the backup are not same as when the ReaR rescue/recovery system was made)

Manually check if those changed files cause issues in your recreated system
Migrating disk-by-id mappings in certain restored files in /mnt/local to current disk-by-id mappings ...
Replacing restored udev rule '/mnt/local//etc/udev/rules.d/70-persistent-net.rules' with the one from the ReaR rescue system
Migrating restored network configuration files according to the mapping files ...
Warning:
Cannot recreate initrd (neither dracut nor mkinitrd found in the recreated system).
Check the recreated system (mounted at /mnt/local)
and decide if the recreated system will boot
with the initrd 'as is' from the backup restore.

Installing GRUB2 boot loader...
Failed to generate boot/grub2/grub.cfg in /mnt/local - trying to install GRUB2 nevertheless
Determining where to install GRUB2 (no GRUB2_INSTALL_DEVICES specified)
Found possible boot disk /dev/vda - installing GRUB2 there
Failed to install GRUB2 on /dev/vda
Failed to install GRUB2 - you may have to manually install it
All /dev/disk/by-id entries in etc/fstab exist as block devices in the recreated system
WARNING:
For this system
SUSE_LINUX/15.6 on Linux-i386 (based on SUSE/15/i386)
there is no code to install a boot loader on the recovered system
or the code that we have failed to install the boot loader correctly.
Please contribute appropriate code to the Relax-and-Recover project,
see http://relax-and-recover.org/development/
Take a look at the scripts in /usr/share/rear/finalize - for example
for PC architectures like x86 and x86_64 see the script
/usr/share/rear/finalize/Linux-i386/660_install_grub2.sh
and for POWER architectures like ppc64le see the script
/usr/share/rear/finalize/Linux-ppc64le/660_install_grub2.sh
---------------------------------------------------
|  IF YOU DO NOT INSTALL A BOOT LOADER MANUALLY,  |
|  THEN YOUR SYSTEM WILL NOT BE ABLE TO BOOT.     |
---------------------------------------------------
You can use 'chroot /mnt/local bash --login'
to change into the recovered system and
manually install a boot loader therein.

Running 'wrapup' stage ======================
Running POST_RECOVERY_SCRIPT 'if snapper --no-dbus -r $TARGET_FS_ROOT get-config | grep -q "^QGROUP.*[0-9]/[0-9]" ; then snapper --no-dbus -r $TARGET_FS_ROOT set-config QGROUP= ; snapper --no-dbus -r $TARGET_FS_ROOT setup-quota && echo snapper setup-quota done || echo snapper setup-quota failed ; else echo snapper setup-quota not used ; fi'
Finished 'recover'. The target system is mounted at '/mnt/local'.
Exiting rear recover (PID 12807) and its descendant processes ...
Running exit tasks
To remove the build area you may use (with caution): rm -Rf --one-file-system /var/tmp/rear.2eNrGdTqLuiGL7l

As expected there is no message that 'tar' got SIGTERM
and the message

Backup restore program tar failed with exit code 2 ...

is all one gets in this case.

When do the same but send SIGTERM to the "main tar process"
instead of the "tar subprocess" as I did before, I get
(excerpts - also after # fg):

RESCUE localhost:~ # rear -D recover
Relax-and-Recover 2.9 / 2025-01-31
Running rear recover (PID 24838 date 2026-09-08 13:12:19)
...
Backup restore program 'tar' started in subshell (PID=30165)
Restored 529 MiB [avg. 108439 KiB/sec] 
Restored 1033 MiB [avg. 105788 KiB/sec] 
^Z
[1]+  Stopped                 rear -D recover


RESCUE localhost:~ # pstree -Aplau 24838
rear,24838 /bin/rear -D recover
  |-rear,30165 /bin/rear -D recover
  |   |-dd,30175 if=/var/tmp/rear.BpLMuvxgQOYGl0Y/outputfs/localhost/backup.tar.gz bs=1M
  |   `-tar,30176 --block-number --totals --verbose --anchored --xattrs --xattrs-include=security.capability --xattrs-include=security.selinux --acls --gzip -C /mnt/local/ -x -f -
  |       `-tar,30177 --block-number --totals --verbose --anchored --xattrs --xattrs-include=security.capability --xattrs-include=security.selinux --acls --gzip -C /mnt/local/ -x -f -
  |           `-gzip,30178 -d
  `-sleep,30193 5


RESCUE localhost:~ # kill 30176


RESCUE localhost:~ # fg
rear -D recover
Restoring 30176 Terminated | $BACKUP_PROG --block-number --totals --verbose -C $TARGET_FS_ROOT/ -x -f - 
OK
Backup restore program tar failed with exit code 143, check /var/log/rear/rear-localhost.log and /var/lib/rear/restore/recover.backup.tar.gz.24838.restore.log and the restored system
Restoring finished (verify backup restore log messages in /var/lib/rear/restore/recover.backup.tar.gz.24838.restore.log)
Created SELinux /mnt/local/.autorelabel file : after reboot SELinux will relabel all files
Recreating directories (with permissions) from /var/lib/rear/recovery/directories_permissions_owner_group
Failed to 'chown root:root bin' 
Failed to 'chown root:root dev' 
...
WARNING:
For this system
SUSE_LINUX/15.6 on Linux-i386 (based on SUSE/15/i386)
there is no code to install a boot loader on the recovered system
...
Finished 'recover'. The target system is mounted at '/mnt/local'.
Exiting rear recover (PID 24838) and its descendant processes ...
Running exit tasks
To remove the build area you may use (with caution): rm -Rf --one-file-system /var/tmp/rear.BpLMuvxgQOYGl0Y

Now there is a message that 'tar' got SIGTERM:

Backup restore program tar failed with exit code 143 ...

jsmeix commented at 2026-09-08 11:33:¶

Finally for completeness:
"rear -D recover" without interruption works well
and the recreated system boots well and
it seems to work normal for me.

FYI:
I did all the above "rear recover" attempts
within one single booted recovery system.
When one interrupts "rear recover"
after the disk layout was recreated
then one must manually umount all
what is mounted under /mnt/local
before one can run "rear recover" again
(otherwise "rear recover" fails with
"The disk layout recreation had failed"):
For example one can umount simply like

RESCUE localhost:~ # umount -a
umount: /mnt/local: target is busy.
umount: /sys/fs/cgroup: target is busy.
umount: /run: target is busy.
umount: /dev: target is busy.
umount: /: not mounted.

RESCUE localhost:~ # mount | grep local
/dev/vda2 on /mnt/local type btrfs (rw,relatime,discard=async,space_cache=v2,subvolid=267,subvol=/@/.snapshots/1/snapshot)
proc on /mnt/local/proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /mnt/local/sys type sysfs (rw,nosuid,nodev,noexec,relatime)

RESCUE localhost:~ # umount /mnt/local/sys /mnt/local/proc /mnt/local

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

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

[Export of Github issue for rear/rear.]

#3634 PR merged: Generic signal reporting¶