ubuntuusers.de

Ich möchte während ein Bash-Sctipt läuft bestimmte oder eventuell auch alle Cronjobgs dieses Users vorübergehend deaktivieren und dann wieder aktivieren.

Beispiel:

Ein Script holt per Fetchmail als User Mails. Während der Maildir-Ordner gerade durch Mail holen verändert wird, ist Sichern von Maildir nicht optimal.

Interessant wäre es wenn die Sicherung läuft, dass das Mail holen als Cronjob deaktiviert wird.

Auf /var/spool/cron/crontabs kann ich nur mit root-Rechten zugreifen, eventuell irgendwie machbar, aber gefällt mir nicht.

Hintergrund, meine lieben Familienmitglieder haben oder finden keine Zeit zum Sichern. Wenn zB 2 Wochen nicht gesichert wird, möchte ich eine lokale Zwangssicherung machen, ganz einfach was mit rsync und tar. Das Backupscript ist schon ziemlich fertig, geht nur mehr um so Sachen wie kaputte Symlinks. Ich sichere einmal mit Symlinks und 1x mit aufgelösten Symlinks, also tatsächliche Files und lösche 1 Datei wenn beide ident sind. Bei mir passt alles, aber bei der lieben Familie ist es etwas chaotisch..

Mein Vorgehen währe

• In dem Script was vom cronjob gestartet wird einfach eine Abfrage ob gerade eine Sicherung gemacht wird, ganz einfach.

Heutzutage macht man so etwas eher mit Systemd-Timern. Und ich bin mir ziemlich sicher, dass Du einem Service sagen kannst, dass er nicht startet, wenn ein anderer läuft.

glaskugel schrieb:

Ein Script holt per Fetchmail als User Mails. Während der Maildir-Ordner gerade durch Mail holen verändert wird, ist Sichern von Maildir nicht optimal.

Interessant wäre es wenn die Sicherung läuft, dass das Mail holen als Cronjob deaktiviert wird.

Hm. Wie lange dauert die Sicherung des Maildirs? Wie oft läuft das Script, das die Mail holt? Wie groß ist die Wahrscheinlichkeit, dass sich die zwei Prozesse 1x im Jahr ins Gehege kommen und dass genau dieses Backup benötigt wird? Hast Du dann noch das vorletzte Backup, oder immer nur eins?

Wenn das 2. Script nicht per cron läuft, sondern interaktiv ist, würde ich eher den Check in dem manuell gestarteten Script machen, weil man da dem User sagen kann, er soll es in 3 Sekunden noch mal probieren (oder probiert es automatisch dann).

Apropos systemd.timer: Systemd-Timer gibt es jetzt auch schon etwa 10 Jahre, oder? Dennoch nutzen alle weiter cron, weil es einfach und robust ist. Ich schätze in 10 Jahren gibt es immer noch cronjobs.

glaskugel schrieb:

Ein Script holt per Fetchmail als User Mails. Während der Maildir-Ordner gerade durch Mail holen verändert wird, ist Sichern von Maildir nicht optimal.

Wenn Du eine Sicherung von Ordnern durchführst, in die auch andere Benutzer schreiben dürfen, ist das richtige Vorgehen, alle Benutzer außer root zeitweise zu sperren und ebenso alle während der Sicherung nicht benötigte Dienste zu stoppen.

Am sichersten geht das durch Booten in den Single-User-Modus und wenn Cron in diesem Modus schon gestartet wurde, musst Du ihn stoppen.

Wenn es unbedingt mit crontab sein soll, kann Du sie ja sichern, löschen und hinterher wiederherstellen:

crontab -l > /Pfad/zur/Sicherungsdatei
crontab -r 
...
Fuehre die Sicherung durch
....
crontab /Pfad/zur/Sicherungsdatei

Bzw. wird bei dem crontab -r auch angegeben, wohin die Datei gespeichert wird. Da weiß ich nicht, ob hier der Dateiname immer der gleiche ist, aber anscheinend schon. Also könntest Du Dir die erste Zeile dann sogar sparen

@glaskugel: Ich verstehe nicht so ganz was das Problem ist. Wenn während der Sicherung ein fetchmail läuft besteht die ”Gefahr”, dass Du mehr Mails sicherst als ohne fetchmail. So what? Das würde ich nicht als Problem ansehen.

Edit: Die tmp/-Unterverzeichnisse hast Du von der Sicherung schon ausgenommen?

@glaskugel: Ich verstehe nicht so ganz was das Problem ist. Wenn während der Sicherung ein fetchmail läuft besteht die ”Gefahr”, dass Du mehr Mails sicherst

Ich habe dann eine halbe Sicherung, ein Teil der Mails sind gesichert, der andere nicht.

Wenn es unbedingt mit crontab sein soll, kann Du sie ja sichern, löschen und hinterher wiederherstellen:

Das kann bei mir der User nicht, da brauche ich root-Rechte.

Am sichersten geht das durch Booten in den Single-User-Modus und wenn Cron in diesem Modus schon gestartet wurde, musst Du ihn stoppen.

Scheint mir mit Kanonen auf Spatzen zu schießen.

Hm. Wie lange dauert die Sicherung des Maildirs?

Das ist Problem Nr.1. Im Normalfall ein paar Minuten, kann aber auch Stunden dauern, zB nach einem Urlaub.

>Wie oft läuft das Script, das die Mail holt?

Zur Zeit alle 15min. Das kann man aber geringfügig ändern. Ich habe vor den Cronjob 5min. nach dem Mail-holen anzusetzen.

Wie groß ist die Wahrscheinlichkeit, dass sich die zwei Prozesse 1x im Jahr ins Gehege kommen und dass genau dieses Backup benötigt wird?

Auch ein Punkt, den man überlegen kann. Unebnötigte Backups sind ja redundant. Aber wenn möglich will ich ein Konzept, das logisch ok ist.

tar: /daten/Maildir-auf-mailsv: Datei hat sich beim Lesen geändert.
Command exited with non-zero status 1

Ist beim Testen passiert.

Hast Du dann noch das vorletzte Backup, oder immer nur eins?

Auch so eine Sache, normalerweise habe ich einige Backups (mit Datum und Zeit). Auf grund des Dateinamens soll ja das Backup automatisch erstellt werden, wenn das Datum zu alt ist.

Wenn das 2. Script nicht per cron läuft, sondern interaktiv ist, würde ich eher den Check in dem manuell gestarteten Script machen

Ich hatte auf was einfacheres gehofft, aber eigentlich habe ich ja schon die Lösung im Script.

Das Fetchmail-Script wird beendet, wenn es schon läuft.

Ich beende einfach das Mail-Holen-Script, wenn das Backup-Script läuft und wenn das Mail-holen-Script läuft, wird das Backup Script beendet. Muss ich mir nur mehr überlegen, wann der nächste Versuch starten soll.

Eine einfache Lösung wäre, eine Lock-Datei anzulegen und mit flock in beiden Skripten exklusiv zu sperren. Du kannst in der Crontab den Eintrag so modifzieren, dass Du nicht kommando arg1 arg2 verwendest sonden flock /run/lock/backup kommando arg1 arg2.

Im Skript kannst Du das so machen

1
2
3
4
5
6
7
8

#!/bin/sh

set -e

exec 9< /run/lock/backup
flock 9

# arbeit

@glaskugel: Eine halbe Sicherung hast Du doch auch wenn Du fetchmail nicht stoppst. Da fehlen dann die Mails die fetchmail geholt hätte. Wenn Du fetchmail weiter laufen lässt hast Du potentiell auch welche von diesen Mails schon in der Sicherung. Das ist doch besser und nicht schlechter.

Es verändern sich auch keine zu sichernden Dateien während der Sicherung. Das kann nur passieren wenn Du die tmp/-Verzeichnisse mit sicherst, und das macht man nicht, weil das keinen Sinn macht unvollständig geschriebene Mails zu sichern. Da entsteht dann beim zurückspielen der Sicherung nur ungenutzter Datenmüll den man dann hoffentlich irgendwann mal aufräumt.

Wie greifen die Nutzer denn auf die Mails zu? Den Dienst müsstest Du stoppen während der Sicherung, nicht individuelle Cron-Jobs. Fetchmail ist hier auch ein bisschen irreführend, denn das kann doch gar nicht mit Maildir umgehen‽

Habe es nicht ganz kapiert. Aber ich bin zur Zeit etwas gestresst, scheine einen Kobold im System zu haben, dazu später.

Fetchmail übergibt an postfix / amavis bzw. dovecot. Vgl. https://wiki.ubuntuusers.de/Archiv/Amavis-Spam-Virenfilter/ Weiß nicht, warum der archiviert ist, läuft unter 24.04 noch genau so, dh die Postfix-Konfigurationen sind seit Jahren unverändert.

Aber wenn fetchmail nichts liefert ändert sich eher auch nichts an den zu sichernden Dateien. Wenn die IMAP-Dateien eventuell verschoben würden, dann sind sie eben am alten oder neuen Platz bei einem Restore. Mir ist wichtig, dass Dateien da sind, die fetchmail geholt hat, aber noch nicht dem User via IMAP zur Verfügung stehen. Das kann schon dauern, wenn ich mir "mailq" ansehe.

Ich kann mir nicht vorstellen wie ein User-Script den dovecot stoppt. Es geht da um eine "Mini-Sicherung". Die Hauptsicherung läuft als root. In der Praxis sind es aber meistens die menschlichen Fehler des Users, die ein Restore benötigen. So in einem Familien-Netz macht man einfach ein paar Kompromisse.

Nun zum Kobold. Plötzlich waren alle Scripts weg. Vorweg, alles von einem anderen PC gerettet

Nachdem ich das Backup-Script organsiatorisch geändert habe, hatte ich alle Sicherungen gelöscht. Als ich fertig war und das Script nochmals testen wollte, konnte ich es nicht aufrufen. /usr/local/bin ist bei mir auf eine "Daten"-Partition verlinkt, damit habe ich es nach einer Neuinstallation einfacher. Der Link war noch da, aber auf der Daten-Partition war der komplette Ordner weg, auch nach einem Reboot. Ok, ich mache viel auf der Konsole und lösche viel mit rm, da denkt man primär daran, ein falsches Verzeichnis gelöscht zu haben, aber in der bash_history war nichts in dieser Richtung zu finden. Da ssh-Verbindung, kommt Löschen per Maus nicht in Frage.

Zur "Kobold-Sache" erwarte ich mir nicht wirklich eine Antwort, aber vielleicht hat ja doch wer eine Idee.