systemd ruft bei Fehlschlag unit bis zu 35 Mal auf

[scientific]

Hi!

Und wieder ein seltsames Phänomen mit systemd.

Ich hab mir jetzt ein nettes Service auf Anregung aus dem Archlinux-Forum https://wiki.archlinux.org/index.php/Sy ... ers#MAILTO gebaut.
Und zwar eine Mailfunktion, wenn eine Unit fehlschlägt.

Grundsätzlich funktioniert das auch wunderbar... Jedoch tritt folgendes auf.
Die Unit für mein Backup sieht so aus:

Code: Alles auswählen

# cat mkbackup@.service 
[Unit]
Description=Make %i-backup from $SYSSUBVOL
ConditionPathExists=!/run/mkbackup-systemd.lock
ConditionPathExists=!/run/btrfs-balance-systemd.lock
Requires=var-cache-btrfs_pool_SYSTEM.mount set-environ.service
Conflicts=suspend.target shutdown.target
Wants=var-cache-backup.mount update-backuplinks.service dpkg-get-selection.service
Before=update-backuplinks.service
After=set-environ.service dpkg-get-selection.service
OnFailure=status-email-root@%n.service

[Service]
Type=simple
EnvironmentFile=/etc/mkbtrbackup.conf.d/%i.conf
#Nice=
IOSchedulingClass=3
#IOSchedulingPriority=
ExecStartPre=/bin/touch /run/mkbackup-systemd.lock
ExecStart=/usr/local/bin/mkbtrbackup create --interval %i  ${SRC}/${SYSSUBVOL} -L ${OPTIONS} 
PIDFile=/var/run/mkbackup_create_%i.pid
ExecStop=/bin/kill -s 2 $MAINPID 
ExecStopPost=-/bin/rm /run/mkbackup-systemd.lock


[Install]
WantedBy=timer-%i.target mkbackup.target

Aktiviert wird diese mit einem timer. %i ist dann z.B. hourly und das Backup wird auch entsprechend erzeugt.
Ich lasse regelmäßig mit einem anderen Service meine btrfs-Partition balancen. Dazu legt dieses Service ein Lock-File an, nach welchem

Code: Alles auswählen

ConditionPathExists=!/run/btrfs-balance-systemd.lock

sucht. Ist das File vorhanden, sollte das Backup nicht gemacht werden (weil sonst zu starke Performance-Einbußen am Laptop sind).

Das passiert auch genau so. Aber nicht einmal, sonder 35 Mal (gezählt) hintereinander. Ich weiß aber jetzt nicht, ob es der Timer so oft hintereinander versucht, die Unit aufzurufen, oder ob die Unit selber 35x versucht neu zu starten.

Der Timer:

Code: Alles auswählen

# cat mkbackup@hourly.timer 
[Unit]
Description=Runs backup %I
PartOf=mkbackup.target

[Timer]
OnCalendar=hourly
Persistent=true
Unit=mkbackup@%i.service

[Install]
WantedBy=mkbackup.target

Und im Journal finde ich folgendes:

Code: Alles auswählen

Sep 30 14:26:09 aldebaran systemd[1]: dpkg-get-selection.service start request repeated too quickly, refusing to start.
Sep 30 14:26:09 aldebaran systemd[1]: set-environ.service start request repeated too quickly, refusing to start.
Sep 30 14:26:09 aldebaran systemd[1]: dpkg-get-selection.service start request repeated too quickly, refusing to start.
Sep 30 14:26:09 aldebaran systemd[1]: set-environ.service start request repeated too quickly, refusing to start.
Sep 30 14:26:09 aldebaran systemd[1]: dpkg-get-selection.service start request repeated too quickly, refusing to start.
Sep 30 14:26:09 aldebaran systemd[1]: set-environ.service start request repeated too quickly, refusing to start.
Sep 30 14:26:09 aldebaran systemd[1]: dpkg-get-selection.service start request repeated too quickly, refusing to start.
Sep 30 14:26:09 aldebaran systemd[1]: set-environ.service start request repeated too quickly, refusing to start.

Hat irgendjemand eine Idee dazu?

lg scientific

[rendegast]

ExecStartPre=/bin/touch /run/mkbackup-systemd.lock
ExecStart=/usr/local/bin/mkbtrbackup create --interval %i ${SRC}/${SYSSUBVOL} -L ${OPTIONS}
...
ExecStop=/bin/kill -s 2 $MAINPID
ExecStopPost=-/bin/rm /run/mkbackup-systemd.lock

Vielleicht ändern in

Code: Alles auswählen

ExecStart=/usr/local/bin/mkbackup/startskript  %i  ${SRC}/${SYSSUBVOL}  -L  ${OPTIONS}
ExecStop=/usr/local/bin/mkbackup/stopscript  $MAINPID

startscript, stopscript:

Code: Alles auswählen

#!/bin/sh
/bin/touch /run/mkbackup-systemd.lock && {
    /usr/local/bin/mkbtrbackup create --interval $@
}

Code: Alles auswählen

#!/bin/sh
/bin/kill -s 2 $1 && {
    /bin/rm /run/mkbackup-systemd.lock
}

?

Würde dann vielleicht weniger systemd-Reloads geben?

[scientific]

Ich habe jetzt etwas spannendes herausgefunden.

Wenn das Service direkt über einen zugehörigen Timer aufgerufen wird (also mkbackup@hourly.timer ruft mkbackup@hourly.service auf), und ein ConditionPathExists schlägt fehl ("does not met"), dann wird die Unit ewig oft gestartet.
Wird das Service über ein Target aufgerufen, das über einen Timer aufgerufen wird, dann nur einmal. Schlägt es fehlt, passiert nichts.

Also liegt das Problem wohl beim Timer.
Etwas ähnliches habe ich auch bei path.Units festgestellt. Schlägt die dazugehörige Unit fehl, ruft die Path-Unit auch die Service-Unit sehr oft hintereinander auf...

Könnte das ein Bug sein? Oder ist das so "by design"?

Hab deine Variante mittels Wrapper-Skript jetzt nicht probiert, da die Variante mit einem Target ja tut, was sie soll... (bzw. fast. Schlägt die Condition fehl, gibts keine OnFailure-Action)

lg scientific