Beiträge von Igel1954

Ich habe mittlerweile auch meine beiden Sicherungen nach systemd überführt.

Die laufen bei z. B. zu folgenden Zeiten:

Montags, Mittwochs und Freitags erfolgt ein Backup mit BorgBackup gegen 7:00, nachdem mein Update-Script ausgeführt worden ist, es werden dabei 3 Sicherungsarchiver (igel01-system-<datetime>, igel01-home-<datetime> und igel01-server-<datetime> erstellt.

Am Sonntag um 00:00:00 Uhr mache ich eine Filesystem-Backup mit fsarchiver für die Filesysteme, die /home, /public, /srv und /VM beinhalten. Zusätzlich mache ich um 9:00 dann noch zusätzlich ein komplettes Backup mit BorgBackup (wie Mo,Mi,Fri)

Für die selbe Aufgabe, die z. B. an unterschiedlichen Tagen und vielleicht sogar dabei auch zu unterschiedlichen Uhrzeiten, ausgeführt werden soll, benötigt man bei Cron mehrere Einträge. Bei systemd reicht ein Timer-File und das dazugehörige Service-File:

[Timer]
OnCalendar=Mon,Wed,Fri *-*-* 07:00:00
OnCalendar=Sun *-*-* 09:00:00

Der OnCalender-Eintrag kann beliebig oft auftreten. Man kann hier für jeden Wochentag, Datum, Uhrzeit unterschiedliche Kombinationen erstellen. Beispiele finden sich in den Man-Pages zu systemd.timer(5).

Für meine Sicherung per BorgBackup sieht das Timer-File so aus:

[Unit]
Description=BorgBackup --timer
Wants=network-online.target

[Timer]
OnCalendar=Mon,Wed,Fri *-*-* 07:00:00
OnCalendar=Sun *-*-* 09:00:00
Persistent=true     
Unit=BorgBackup.service

[Install]
WantedBy=multi-user.target

Das dazugehörige Service-File sieht so aus:

[Unit]
Description=BorgBackup --service
#
# hier kann man den Service kommentieren.
#
Requires=NetworkManager.service NetworkManager-wait-online.service
After=network-online.target

[Service]
Type=oneshot
NotifyAccess=exec 
StandardOutput=file:/var/log/BorgBackup.log 
StandardError=inherit

Environment="SHELL=/bin/bash" "PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin"

User=root
Group=root 

#Nice=19
#IOSchedulingClass=2
#IOSchedulingPriority=7

ExecStart=bash -lc '/usr/local/bin/BorgBackup.rex  '


[Install]
WantedBy=multi-user.target

Der Install-Block kann Einsatz eines Timers wohl auch weggelassen werden. Da ich mir hier aber nicht ganz sicher bin, ist dieser Block halt in beiden Files vorhanden.

Mit systemctl list-timers kann man kontrollieren, ob eine Timer-Aufgabe durchgeführt wurde und wann sie das nächste Mal wieder ausgeführt wird.

Das sieht dann in etwa so aus:

igel01:~ # systemctl list-timers
NEXT                         LEFT          LAST                         PASSED        UNIT                         ACTIVATES                     
Mon 2022-08-22 23:40:27 CEST 48min left    Mon 2022-08-22 21:43:43 CEST 1h 8min ago   dnf-makecache.timer          dnf-makecache.service         
Tue 2022-08-23 00:00:00 CEST 1h 7min left  Mon 2022-08-22 00:00:01 CEST 22h ago       logrotate.timer              logrotate.service             
Tue 2022-08-23 00:00:00 CEST 1h 7min left  Mon 2022-08-22 00:00:01 CEST 22h ago       mandb.timer                  mandb.service                 
Tue 2022-08-23 00:00:00 CEST 1h 7min left  Mon 2022-08-22 00:00:01 CEST 22h ago       mlocate.timer                mlocate.service               
Tue 2022-08-23 01:07:45 CEST 2h 15min left Mon 2022-08-22 01:46:53 CEST 21h ago       backup-sysconfig.timer       backup-sysconfig.service      
Tue 2022-08-23 13:07:42 CEST 14h left      Mon 2022-08-22 19:22:07 CEST 3h 29min ago  suseconnect-keepalive.timer  suseconnect-keepalive.service 
Tue 2022-08-23 18:10:01 CEST 19h left      Mon 2022-08-22 18:10:01 CEST 4h 42min ago  systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Wed 2022-08-24 00:00:00 CEST 1 day 1h left Mon 2022-08-22 00:00:01 CEST 22h ago       Update_OS.timer              Update_OS.service             
Wed 2022-08-24 07:00:00 CEST 1 day 8h left Mon 2022-08-22 07:00:01 CEST 15h ago       BorgBackup.timer             BorgBackup.service            
Sun 2022-08-28 00:00:00 CEST 5 days left   Sun 2022-08-21 00:00:01 CEST 1 day 22h ago BackupFS.timer               BackupFS.service              
Mon 2022-08-29 00:23:22 CEST 6 days left   Mon 2022-08-22 00:43:53 CEST 22h ago       fstrim.timer                 fstrim.service                

11 timers listed.
Pass --all to see loaded but inactive timers, too.
igel01:~ # 

Zitat von Sauerland

Mal ne Frage:

willst du dies nicht nach howtos verschieben (lassen)?

Du hast recht - da ist es doch besser aufgehoben. Ich hab Alero 'ne PM geschrieben, damit der Thread verschoben wird. Ich hoffe er kann dabei den Titel etwas anpassen.

Für alle, die sich auch für systemd anstelle von cron für die regelmäßige Ausführung bestimmter Aufgaben interessieren, kommt hier noch ein wichtiger Hinweis.

Unter openSuSE LEAP 15.3 werkelt systemd 246. Die Man-Pages zu systemd auf Freedesktop.org (z. B. : http://www.freedesktop.org/sof…md/man/systemd.timer.html) beziehen sich schon auf systemd 251. Hier gibt es einige Angaben, die unter systemd 246 zu einer Fehlermeldung führen. Ich bin da nämlich bei den möglichen Angaben für StandardOutput auf eine Fehlermeldung gelaufen:

/etc/systemd/system/Update_OS.service:13: Failed to parse output specifier, ignoring: truncate:/var/log/Update_OS.log

Beispiel:

systemd 246: kennt nur StandardOutput = file:/pfad/datei oder StandardOutput = append:/pfad/datei..

systemd 251: kennt auch StandardOutput= truncate:/pfad/datei.

Ich steuere das über die Zypper-Exitcodes.
Hier mal der Ablauf meines Scriptes:

1. zypper --gpg-auto-import-keys --non-interactive ref 
   geht hier etwas schief, schläft das Script für 1800 Sekunden. Nach dem 5. vergeblichen Refreshes wird das Script abgebrochen
2. zypper -vvv pchk --with-optional
   gibt es Patches bekomme ich von Zypper den Exitcode 100 oder 101 gemeldet.
3. Bei Exitcode 100 oder 101 zypper -vvv patch -y -l --with-optional --with-interactive
   Bei Exitcode 103 wurde zypper upgedatet und der Patch-Befehl wird nochmal abgesetzt.
   Hier bekomme ich entweder einen Exitcode = 0 dann ist alles ok, bei Exitcode 102 setzte ich einen Schalter, dass ein Reboot erforderlich ist.
   Man könnte dem Patch-Befehl noch --with-updates mitgeben, dann würden die Updates aus den anderen Repos direkt mit verarbeitet. Ich hab es für mich aber absichtlich getrennt, damit ich in dem Log eine getrennte Übersicht habe, welche Patches und welche Updates installiert wurden. Ist in meinen Augen übersichtlicher.
4. Da Patches nur aus den OSS bzw. NON-OSS -Repos kommen, ich aber auch Packages aus dem Packman- Printing-, und Mozilla-Repo habe macht mein Script jetzt noch
   zypper -vvv up -y -l --details --with-interactive, damit ich hier die geänderten Packages bekomme.
5. Bevor jetzt mein Script zur Endeverarbeitung kommt, setzte ich sicherheitshalber nach ein zypper needs-rebooting ab. Ist ein Reboot erforderlich, bekomme ich hier auch wieder den Exitcode 102 und kann den Reboot-Schalter auf True setzen.
6. Da jetzt das Script in der Endeverarbeitung ist, wird hier der Reboot-Schalter abgefragt.
   Ist er gesetzt, dann erfolgt der Shutdown -r Befehl. Ich lasse den Shutdown 30 Minuten verzögern, damit mein Script ordnungsgemäß beendet wird. Die Verzögerungszeit ist von mir willkürlich gewählt. Man kann Shutdown auch auf eine bestimmte Uhrzeit setzen oder der verzögerungszeit verkürzen oder verlängern.

Ich hab mir die Zypper-Exitcodes aus der Zypper-Doku in ein extra Textfile kopiert. Ich hänge es mal an meine Antwort mit an.

Zypper_Returncodes.txt

Wenn es ein AppImage ist, dann müsste es doch auf jeder Linux-Umgebung laufen, unabhängig davon, welche Versionen von Interpretern/Runtime-Umgebungen tatsächlich installiert ist.

Das ist zumindest meine Auffassung zum Sinn eines AppImages.

Zitat von JeyF123

Komischerweise habe ich gar keine Benachrichtigung erhalten, obwohl du mich getagged hast.

Das kannst du einstellen. Oben auf den Menüpunkt Benachrichtigungen und dann auf das Zahnrad klicken. Dann kannst du einstellen, welche Benachrichtigungen du bekommen willst.

Inspiriert durch das Thema von JeyF123 über Probleme mit Cron und den Hinweisen von Sauerland zu systemd-timer als Cron-Alternative, habe ich mich mal an der Überführung einer meiner Cron-Aufgaben nach Systemd versucht.

Die Aufgabenstellung in meiner /etc/crontab für das EInspielen von Patches und Updates:

  GNU nano 4.9.2                                                                      /etc/crontab                                                                      
 1 SHELL=/bin/bash
 2 PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin
 3 MAILTO=root
 4 #
 8 #
 9 # Mo, MI, Fri openSUSE-Updates einspielen
10 #
11 0      0   *   *   1,3,5  root    bash -lc 'Update_OS.rex '
12 #

An drei Tagen (Montag, Mittwoch, Freitag) lasse ich durch cron ein Script laufen, das per zypper alle für mich notwendigen Patches und Updates auf meinem Desktop installiert.

An Hand der Zypper-Returncodes ermittelt das Script auch, ob ein Reboot des Systems erforderlich ist und setzt als letzte Anweisung shutdown -r +30 "Rechner wird in 30 Minuten durchgestartet" ab. Für mich wichtige Informationen schreibt das Script per logger auch in das Journal.

Um diese Aufgabe per systemd zu lösen, hab ich mich an dem Beispiel von Michael Kofler (https://kofler.info/systemd-timer-als-cron-alternative/) orientiert und in /etc/systemd/system die Dateien Update_OS.timer und Update_OS.service angelegt.

[Unit]
Description=Update_OS --timer
Wants=network-online.target

[Timer]
OnCalendar=Mon,Wed,Fri
Persistent=true     
Unit=Update_OS.service

[Install]
WantedBy=multi-user.target

[Unit]
Description=Update_OS --service
#
# Automatisches Einspielen von Patches und Updates
# durch zypper, der per REXX-PScript aufgerufen wird
#
Requires=NetworkManager.service NetworkManager-wait-online.service
After=NetworkManager.service

[Service]
Type=oneshot
NotifyAccess=exec 
StandardOutput=file:/var/log/Update_OS.log
StandardError=inherit

User=root
Group=root 

#Nice=19
#IOSchedulingClass=2
#IOSchedulingPriority=7
ExecStart=/bin/bash -lc '/usr/local/bin/Update_OS.rex  '

[Install]
WantedBy=multi-user.target

Da ja im Gegensatz zur Ausführung der Aufgabe mit Cron von Systemd keine E-Mail kommt, lasse ich alle Ausgaben in eine Log-Datei schreiben.

Mit systemctl enable --now Update_OS.timer wird der Timer aktiviert. Durch die Option --now spart man sich die zusätzliche Start-Anweisung.

Beim Start meldet Systemd auch Syntax-Fehler. Ich hab dann mehrfach den Timer wieder disablen müssen, um die Timer- bzw. Service-Datei zu korrigieren. Bis beide Dateien anstandslos von Systemd anerkannt wurden, hab ich reichlich Gebrauch von den entsprechenden Man-Pages per Browser gemacht.

Bei Änderungen am aktiven Timer bzw. Service muß dieser per systemctl reenable --now <timername>.timer oder per systemctl daemon-reload aktualisieren.

Ich hab für die Umstellung von Cron nach Systemd ca. 7-8 Stunden mit Unterbrechungen (genau weiß ich es nicht) benötigt.

Die Umstellung der restlichen Cron-Aufgaben (2 Sicherungsaufgaben mit fsarchiver bzw. BorgBackup) werden als nächstes in Angriff genommen.

Ob die beiden Dateien vom Inhalt her optimal aufgebaut sind, müssen Systemd-Kundige beurteilen, für meine Zwecke reicht das.

Zitat von Sauerland

Igel1954

Wenn du Leap 15.3 hast, vor dem Update die beiden obigen Pakete mit dem Befehl installieren und danach das Update machen.

Das sollte genügen.

Danke, nach der Installation der beiden Pakete hat Zypper mir auch die Nvidia G04 390.154 Pakete zum Update angeboten. Jetzt läuft mein System mit dem aktuellen Treiber.

Zitat von Omegator

Mit dem Wechsel lasse ich mir immer relativ lange Zeit, also genau genommen warte ich immer fast bis zum Schluß.

Ich warte auch immer bis zum Schluss bei meinem Rechner. Den Rechner meiner Frau mach ich meist ein bisschen vorher, da ist nicht so viel installiert.

Ich will jetzt den Thread nicht kapern, aber ich müsste eigentlich auch auf den aktuellen G04-Treiber für meine Geforce GT610 updaten.

Und der Fehler auf den Omegator gelaufen ist, wirft jetzt bei mir Fragen auf, ob ich evtl. auch auf diesen Fehler laufen würde. Das würde ich am liebsten im Vorfeld verhindern wollen.

Im Moment nutzt mein System noch den 390.151. Zypper lu bietet mir den aktuellen Treiber (390.154) nicht mal zum Update an, nur im YAST sehe ich die neue Version.

Hängt das damit zusammen, dass SuSE in den Namen der Kernelmodule diese 150300 dazwischen gesetzt hat?