blog · git · desktop · images · contact
2014-07-30
Seit einiger Zeit setzt Arch Linux ziemlich konsequent auf die Benutzung von systemd timers. Ein Basissystem hat gar keinen Cron mehr vorinstalliert, wenn ich mich nicht irre.
Ich habe die letzten Jahre fcron benutzt. Hauptsächlich, weil es Cron und Anacron in einem ist. Es kann also nicht nur Jobs zu festen Zeiten planen, sondern diese auch nachholen, wenn der Rechner zur geplanten Zeit ausgeschaltet war. Das ist ein Feature, was ich auf Desktop-Systemen für unerlässlich halte.
fcron ist allerdings nicht fehlerlos. Immer wieder ist es passiert, dass er Jobs „vergessen“ hat oder bei dessen Ausführung etwas schiefgelaufen ist. Das ist schlecht, weil ich mich auf einen Cron verlassen können will. Mangels Alternative habe ich mich aber damit abgefunden. Kürzlich wurde aber der Leidensdruck zu groß und ich wollte etwas haben, das auch funktioniert.
Erst wollte ich zu cronie greifen. Dann habe ich mich gefragt: „Brauche ich überhaupt einen Cron? Ist nicht das, was ich brauche, ein Anacron?“ Stellt sich heraus, dass das stimmt. Ich brauche etwas, das in regelmäßigen Abständen Jobs ausführt – manches in Abständen von ein paar Minuten, anderes in Abständen von einer Woche. Mich interessiert dabei auch wirklich nur die Frequenz und nicht der genaue Wochentag oder so. Außerdem muss das Programm pro User sehr leicht zu konfigurieren sein. Durch letzteres fallen systemd timers schon einmal raus. cronie enthält einen Anacron, hat mich aber durch die Benutzung der Autotools direkt abgeschreckt. Warum das relevant ist?
Ich habe eine lästige Angewohnheit, die sich in letzter Zeit intensiviert hat: Wo immer möglich, lese ich mir den Quellcode der Software, die ich einsetze, durch. Ich will verstehen, wie die Software funktioniert und was sie genau tut. Im Zweifel will ich sie ändern können. Außerdem möchte ich, dass die Software sinnvoll ist und nicht einfach achtzig Features hat, nur weil sie nett sind. Meine Wünsche werden in der Regel von Software aus dem suckless-Umfeld prima erfüllt. Leider gibt es von den Jungs direkt keinen Anacron-Ersatz, lediglich scron wird empfohlen, was aber nicht ganz das tut, was ich brauche.
Enter regularly. Ein Shellskript, das im Moment aus 40 Zeilen besteht und dafür sorgt, dass Jobs in regelmäßigen Abständen ausgeführt werden. Bei Fehlern oder vorhandener Ausgabe schickt es mir eine Mail. Ausführungen werden an Syslog (oder eben journald) geloggt. Gestartet wird es über eine while-Schleife. That's it. Mehr will ich gar nicht. Damit habe ich fcron abgelöst.
Ist das eine gute Idee? Ist selbstgeschriebene Software nicht im Zweifel fehleranfälliger als ein Projekt, das schon mehrere Jahre existiert und gut gereift ist? Tendenziell ja. In diesem Fall aber, bei diesen klar definierten Anforderungen und deren sehr geringem Umfang, da traue ich mir zu, dass ich das einigermaßen vernünftig auf die Reihe kriege.
Mein Ziel ist nicht, jede Komponente des Systems durch etwas eigenes zu ersetzen. Vielmehr möchte ich an möglichst vielen Stellen sinnvolle, verständliche und minimalistische Software haben, die ihre Arbeit gut macht. Ich bin dabei noch lange nicht am Ziel und wahrscheinlich ist das auch einfach ein fortwährender Prozess. Und diese Denkweise möchte ich mit Blogpostings dieser Art transportieren. Ich möchte dazu motivieren, den Sinn jeder Zeile Code, die auf dem eigenen Rechner so läuft, zu hinterfragen. Ist das alles notwendig? Ginge es nicht auch mit weniger? Fehlt irgendwas? Ginge das eine oder andere vielleicht auch besser? Wie oft wird möglicherweise sehr komplexer Code überhaupt benutzt? Löst die Software eigentlich das richtige Problem oder ist sie nur ein Workaround? Und so weiter.
Kurzum: Ist das sinnvoll?