#2139 Issue `closed`: Provide a systemd service and timer to run "rear checklayout || rear mkrescue"¶

Labels: enhancement, documentation, no-issue-activity

jsmeix opened issue at 2019-05-09 06:36:¶

In https://github.com/rear/rear/issues/1892 via
https://github.com/rear/rear/commit/89a8f18ec402b439caf4800421644f5bf5d174e5
the /etc/cron.d/rear/ related things were removed for ReaR 2.5
(see that issue for the reasoning behind)
and instead a systemd service and timer to run

/usr/sbin/rear checklayout || /usr/sbin/rear mkrescue

should be provided and described in the documentation for ReaR 2.6.

See https://github.com/rear/rear/issues/1892#issuecomment-456018031
excerpts:

rmetrich commented on Jan 21
...
This automatic cron is broken and leads to
having broken ReaR ISOs at the end,
in my opinion, we should remove this file and
provide a systemd service + timer instead,
which wouldn't be enabled by default.

Example:

rear-rescue-iso.timer
-------------------------------------------------------
[Unit]
Description=ReaR ... Creation Timer Task
Documentation=man:rear(8)
After=network.target

[Timer]
OnCalendar=daily
RandomizedDelaySec=14400

[Install]
WantedBy=multi-user.target
-------------------------------------------------------

rear-rescue-iso.service
-------------------------------------------------------
[Unit]
Description=ReaR ... Creation
Documentation=man:rear(8)
After=network.target

[Service]
Type=simple
ExecStart=/bin/sh -c '/usr/sbin/rear checklayout || /usr/sbin/rear mkrescue'
Restart=no
WatchdogSec=600
BlockIOWeight=100
-------------------------------------------------------

OliverO2 commented at 2019-05-09 20:45:¶

Just some small input for future systemd units:

rear mkrescue is not a continuously running service, right? So Type=oneshot would be correct.
A ReaR service requiring the network to be operational should probably run after network-online.target as (AFAIK) ReaR does not support waiting for network services to become available. Cf. Running Services After the Network is up.
If a timer should work on laptops and desktops which are not always on, it could be made persistent to avoid missing scheduled times. Also, it could be made to avoid running on battery power.

This is modeled after services and timers I use for backups (though I use different timers for desktops and servers):

rear-rescue.service:

[Unit]
Description=Relax-and-Recover Rescue System Update Service
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
# lowest CPU priority
Nice=19
# lowest I/O priority among 'normal' processes
IOSchedulingClass=best-effort
IOSchedulingPriority=7
ExecStart=/bin/sh -c '/usr/sbin/rear checklayout || /usr/sbin/rear mkrescue'

rear-rescue.timer:

[Unit]
Description=Relax-and-Recover Rescue System Update
ConditionACPower=true

[Timer]
OnCalendar=19:15
AccuracySec=1 second
Persistent=true

[Install]
WantedBy=timers.target

rmetrich commented at 2019-05-10 06:54:¶

@OliverO2 You are right. Feel free to create a PR and I'll be happy to merge it :-)
From my proposal, I would keep the following properties:

WatchdogSec=600
BlockIOWeight=100

OliverO2 commented at 2019-05-10 15:08:¶

@rmetrich I'll take a closer look and submit a proposal once ReaR 2.5 is released.

I'm fine with the intention of your parameters, but if I understand correctly, they might need to be tweaked a bit:

WatchdogSec would be ineffective with Type=oneshot as such processes (from a systemd point of view) do nothing but start up, and systemd.service(5) says: The watchdog is activated when the start-up is completed. I'd guess that TimeoutStartSec=10 minutes would do the job of limiting total run time accordingly.
BlockIOWeight is deprecated and now superceded by IOWeight. Nevertheless it might be a good idea to keep it for some time, but we should probably first take a look at systemd versions and control group interface versions (v1 or v2) on systems supported by ReaR. See NOTES section in systemd.resource-control(5)

rmetrich commented at 2019-05-13 06:24:¶

Sorry @OliverO2 , I wasn't clear enough. Here is the proposed service unit:

[Unit]
Description=Relax-and-Recover Rescue System Update Service
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
# lowest CPU priority
Nice=19
# lowest I/O priority among 'normal' processes
IOSchedulingClass=best-effort
IOSchedulingPriority=7
BlockIOWeight=100
WatchdogSec=600
Restart=no
ExecStart=/bin/sh -c '/usr/sbin/rear checklayout || /usr/sbin/rear mkrescue'

Regarding IOWeight property versus BlockIOWeight, I don't know if we should use the first, because there may be incompatibilities with some OSes running older systemd releases, such as RHEL7 that only recognizes BlockIOWeight.

adatum commented at 2019-08-14 02:36:¶

What do you think of using systemd-inhibit on the ExecStart command to prevent the system from being suspended or shutdown while mkrescue (or even a backup) is being run?

Also, is there a reason why RandomizedDelaySec seems to have been dropped even though Persistent=true is proposed?

There is a similar discussion over at borgmatic https://projects.torsion.org/witten/borgmatic/issues/205

Also, I agree with the decision to remove /etc/cron.d/rear, and I hope the systemd service and timer provided or documented will be optional and not enabled by default. Having it enabled by default could result in useless ISOs made without proper configuration, and also compete with alternative backup solutions.

As an example, my plan is to:

use ReaR to create system recovery media
use Borg for system backup
use borgmatic to run Borg backups AND run rear checklayout || rear mkrescue in a pre-backup hook
schedule borgmatic with a systemd timer and service

gdha commented at 2019-09-13 08:05:¶

@rmetrich @adatum Could you agree on the content of the systemd script to include in our documentation so we can close this issue?

adatum commented at 2019-09-13 17:49:¶

I have posted here the systemd scripts I have been running for the past couple of weeks mostly based on what @rmetrich already suggested. So far so good.

Main differences are:

launching with systemd-inhibit to prevent interrupting backups
combining a X minute sleep and setting the timer X minutes earlier as a workaround to avoiding starting a backup immediately upon system startup in case Persistent=true were triggered

OliverO2 commented at 2019-11-18 12:28:¶

With respect to my suggestion above to come up with a PR: After rethinking the scenario, I have decided against using an automatic service to update recovery media. While my backup media contents are automatically and regularly tested for completeness and integrity, I cannot do likewise with ReaR-generated recovery media. These have to be hand-tested or else I'd risk losing recovery capability.

If the intention remains to come up with a systemd service, I'd suggest to have this disabled by default and to provide user information about the implications of enabling it. In that case, the above suggestion of @rmetrich seems to be OK with the exception of WatchdogSec which should be removed for clarity. Just my 2 cents...

jsmeix commented at 2019-11-18 15:01:¶

@OliverO2
at least for SUSE and openSUSE our packaging rules forbid
in general (except a few carefully evaluated and approved exceptions)
to have any kind of "service" (i.e. some "thingy" that runs automatically)
enabled by default (i.e. it is active after plain installing the RPM package),
cf. https://github.com/rear/rear/issues/1892#issuecomment-410973078
and https://github.com/rear/rear/issues/1892#issuecomment-456005881

github-actions commented at 2020-06-29 01:37:¶

Stale issue message

[Export of Github issue for rear/rear.]

#2139 Issue closed: Provide a systemd service and timer to run "rear checklayout || rear mkrescue"¶