Der Klassiker schrieb, dass glückliche Stunden nicht beobachtet werden. In jenen wilden Zeiten gab es weder Programmierer noch Unix, aber heutzutage wissen Programmierer fest: Anstelle von ihnen kümmert sich cron um die Zeit.
Kommandozeilen-Utilities sind für mich gleichzeitig Schwäche und Routine. sed, awk, wc, cut und andere alte Programme werden täglich über Skripte auf unseren Servern gestartet. Viele von ihnen sind als Aufgaben für cron angelegt, einem Scheduler aus den 70ern.
Ich habe cron lange oberflächlich genutzt, ohne in die Details einzutauchen, aber eines Tages, als ich bei der Ausführung eines Skripts auf einen Fehler stieß, beschloss ich, mich eingehend damit zu beschäftigen. So entstand dieser Artikel, bei dessen Schreiben ich mich mit POSIX crontab, den Hauptvarianten von cron in beliebten Linux-Distributionen und dem Aufbau einiger davon vertraut machte.
Benutzen Sie Linux und führen Sie Aufgaben in cron aus? Interessiert Sie die Architektur der Systemanwendungen in Unix? Dann sind wir auf dem richtigen Weg!
Inhalt
Die Entstehung der Arten
Die periodische Ausführung von Benutzer- oder Systemprogrammen ist in allen Betriebssystemen eine offensichtliche Notwendigkeit. Daher wurde der Bedarf an Diensten, die die zentrale Planung und Ausführung von Aufgaben ermöglichen, von Programmierern schon lange erkannt.
Unix-basierte Betriebssysteme stammen von Version 7 Unix ab, das in den 70er Jahren des letzten Jahrhunderts in den Bell Labs, unter anderem von dem berühmten Ken Thompson, entwickelt wurde. Zusammen mit Version 7 Unix wurde auch cron ausgeliefert, ein Dienst zur regelmäßigen Ausführung von Aufgaben des Superbenutzers.
Ein typisches modernes cron ist ein einfaches Programm, aber der Algorithmus des ursprünglichen Modells war noch einfacher: Der Dienst wachte jede Minute auf, las die Tabelle mit den Aufgaben aus einer einzigen Datei (\/etc\/lib\/crontab) und führte für den Superbenutzer die Aufgaben aus, die in der aktuellen Minute erledigt werden sollten.
Später wurden verbesserte Varianten des einfachen und nützlichen Dienstes mit allen Unix-ähnlichen Betriebssystemen ausgeliefert.
Allgemeine Beschreibungen des crontab-Formats und der grundlegenden Funktionsprinzipien der Utility wurden 1992 in den Hauptstandard der Unix-ähnlichen Betriebssysteme – POSIX – aufgenommen und somit wurde cron von de facto zum de jure Standard.
Im Jahr 1987 veröffentlichte Paul Vixie, der Unix-Benutzer nach Wünschen an cron befragte, eine weitere Version des Daemons, die einige Probleme des traditionellen cron behob und die Syntax der Tabellen-Dateien erweiterte.
Mit der dritten Version erfüllte Vixie cron die Anforderungen von POSIX. Zudem hatte das Programm eine liberale Lizenz, oder besser gesagt, es gab überhaupt keine Lizenz, abgesehen von den Wünschen im README: Es gibt keine Garantien vom Autor, der Name des Autors darf nicht entfernt werden, und das Programm darf nur zusammen mit dem Quellcode verkauft werden. Diese Anforderungen waren kompatibel mit den Prinzipien der in diesen Jahren an Popularität gewinnenden Free Software, weshalb einige der wichtigsten früh in den 90er Jahren erschienen Linux-Distributionen Vixie cron als systematisch einsetzten und es bis heute weiterentwickeln.
Insbesondere Red Hat und SUSE entwickeln einen Fork von Vixie cron – cronie, während Debian und Ubuntu die originale Version von Vixie cron mit vielen Patches verwenden.
Lassen Sie uns zunächst mit dem in POSIX beschriebenen Benutzerwerkzeug crontab vertrautmachen, danach werden wir die Syntaxerweiterungen untersuchen, die in Vixie cron vorgestellt werden, und die Verwendung von Variationen von Vixie cron in beliebten Linux-Distributionen. Und schließlich das i-Tüpfelchen – die Analyse des Daemon-Geräts cron.
POSIX crontab
Wenn der ursprüngliche cron immer für den Superbenutzer arbeitete, haben moderne Scheduler häufiger mit Aufgaben gewöhnlicher Benutzer zu tun, was sicherer und bequemer ist.
Cron wird als Paket aus zwei Programmen geliefert: einem ständig laufenden Daemon cron und dem für Benutzer zugänglichen Werkzeug crontab. Letzteres ermöglicht die Bearbeitung von auf jeden Benutzer im System spezifischen Aufgabenlisten, während der Daemon Aufgaben aus den Benutzer- und der systemweiten Tabelle ausführt.
Im beschreibt das Verhalten des Daemons nicht und formalisiert nur das Benutzerprogramm . Die Existenz von Mechanismen zum Starten von Benutzeraufgaben wird zwar implizit vorausgesetzt, aber nicht im Detail beschrieben.
Mit dem Aufruf des Werkzeugs crontab können vier Dinge getan werden: Bearbeiten der Benutzertabelle im Editor, Laden der Tabelle aus einer Datei, Anzeigen der aktuellen Aufgabendatei und Löschen der Aufgabendatei. Beispiele für die Verwendung des Werkzeugs crontab:
crontab -e # Tabelle bearbeiten
crontab -l # Tabelle anzeigen
crontab -r # Tabelle löschen
crontab path/to/file.crontab # Tabelle aus der Datei ladenBeim Aufruf von crontab -e Es wird der in der Standardumgebungsvariable angegebene Editor verwendet EDITOR.
Die Aufgaben selbst sind im folgenden Format beschrieben:
# строки-комментарии игнорируются
#
# задача, выполняемая ежеминутно
* * * * * /path/to/exec -a -b -c
# задача, выполняемая на 10-й минуте каждого часа
10 * * * * /path/to/exec -a -b -c
# задача, выполняемая на 10-й минуте второго часа каждого дня и использующая перенаправление стандартного потока вывода
10 2 * * * /path/to/exec -a -b -c > /tmp/cron-job-output.logDie ersten fünf Felder der Einträge: Minuten [1..60], Stunden [0..23], Tage des Monats [1..31], Monate [1..12], Wochentage [0..6], wobei 0 Sonntag ist. Das letzte, sechste Feld ist eine Zeile, die vom standardmäßigen Befehlsinterpreter ausgeführt wird.
In den ersten fünf Feldern können die Werte durch Kommas aufgelistet werden:
# задача, выполняемая в первую и десятую минуты каждого часа
1,10 * * * * /path/to/exec -a -b -cOder durch einen Bindestrich:
# задача, выполняемая в каждую из первых десяти минут каждого часа
0-9 * * * * /path/to/exec -a -b -cDer Zugriff der Benutzer auf die Planung von Aufgaben wird durch die POSIX-Dateien cron.allow und cron.deny reguliert, in denen entsprechend die Benutzer mit Zugang zu crontab und die Benutzer ohne Zugang zum Programm aufgeführt sind. Der Standort dieser Dateien wird durch den Standard nicht geregelt.
Den gestarteten Programmen müssen gemäß dem Standard mindestens vier Umgebungsvariablen übergeben werden:
- HOME — das Home-Verzeichnis des Benutzers.
- LOGNAME — der Benutzername.
- PATH — der Pfad, in dem die Standard-Hilfsprogramme des Systems gefunden werden können.
- SHELL — der Pfad zum verwendeten Befehlsinterpreter.
Bemerkenswert ist, dass POSIX nichts darüber sagt, woher die Werte für diese Variablen stammen.
Bestseller – Vixie cron 3.0pl1
Der gemeinsame Vorfahre der populären cron-Varianten ist Vixie cron 3.0pl1, das 1992 in der Mailingliste comp.sources.unix vorgestellt wurde. Die Hauptmerkmale dieser Version werden wir näher betrachten.
Vixie cron wird in zwei Programmen (cron und crontab) bereitgestellt. Wie gewöhnlich ist der Daemon für das Lesen und Ausführen von Aufgaben aus der systemweiten Aufgabenliste und den Aufgabenlisten einzelner Benutzer verantwortlich, während das Tool crontab für die Bearbeitung der Benutzertabellen zuständig ist.
Aufgabenliste und Konfigurationsdateien
Die Aufgabenliste des Superbenutzers befindet sich in /etc/crontab. Die Syntax der systemweiten Tabelle entspricht der Syntax von Vixie cron mit der Abweichung, dass in der sechsten Spalte der Benutzername angegeben wird, unter dessen Konto die Aufgabe gestartet wird:
# Запускается ежеминутно от пользователя vlad
* * * * * vlad /path/to/execDie Aufgabenlisten der normalen Benutzer befinden sich in /var/cron/tabs/benutzername und verwenden die gemeinsame Syntax. Wenn das Tool crontab im Namen eines Benutzers ausgeführt wird, werden genau diese Dateien bearbeitet.
Die Verwaltung der Listen der Benutzer, die Zugriff auf crontab haben, erfolgt in den Dateien /var/cron/allow und /var/cron/deny, wo es lediglich nötig ist, den Benutzernamen in einer einzelnen Zeile einzutragen.
Erweiterte Syntax
Im Vergleich zu POSIX crontab enthält Paul Vixies Lösung mehrere sehr nützliche Modifikationen in der Syntax der Aufgabenlisten des Tools.
Eine neue Tabellen-Syntax ist verfügbar: Zum Beispiel können Wochentage oder Monate namentlich angegeben werden (Mon, Tue usw.):
# Запускается ежеминутно по понедельникам и вторникам в январе
* * * Jan Mon,Tue /path/to/execEs kann ein Schritt angegeben werden, nach dem Aufgaben gestartet werden:
# Запускается с шагом в две минуты
*/2 * * * Mon,Tue /path/to/execSchritte und Intervalle können gemischt werden:
# Запускается с шагом в две минуты в первых десять минут каждого часа
0-10/2 * * * * /path/to/execIntuitive Alternativen zur üblichen Syntax werden unterstützt (reboot, yearly, annually, monthly, weekly, daily, midnight, hourly):
# Запускается после перезагрузки системы
@reboot /exec/on/reboot
# Запускается раз в день
@daily /exec/daily
# Запускается раз в час
@hourly /exec/dailyAufgaben-Ausführungsumgebung
Vixie cron ermöglicht es, die Umgebung der gestarteten Anwendungen zu ändern.
Die Umgebungsvariablen USER, LOGNAME und HOME werden nicht einfach vom Daemon zur Verfügung gestellt, sondern aus einer Datei entnommen. Die Variable PATH erhält den Wert "\/usr\/bin:\/bin", und SHELL – "\/bin\/sh". Die Werte aller Variablen, außer LOGNAME, können in den Benutzertabellen geändert werden.
Einige Umgebungsvariablen (vor allem SHELL und HOME) werden von cron selbst verwendet, um Aufgaben zu starten. So könnte die Verwendung von bash anstelle des standardmäßigen sh zur Ausführung von Benutzeraufgaben aussehen:
SHELL=\/bin\/bash
HOME=\/tmp\/\n# exec wird in bash in \/tmp\/ gestartet
* * * * * \/path\/to\/execLetztendlich werden alle in der Tabelle definierten Umgebungsvariablen (die von cron verwendet oder für den Prozess benötigt werden) an die gestartete Aufgabe übergeben.
Um Dateien mit dem Tool crontab zu bearbeiten, wird der Editor verwendet, der in der Umgebungsvariable VISUAL oder EDITOR angegeben ist. Wenn diese Variablen in der Umgebung, in der crontab gestartet wurde, nicht definiert sind, wird "\/usr\/ucb\/vi" verwendet (ucb ist wahrscheinlich für die University of California, Berkeley).
cron in Debian und Ubuntu
Die Entwickler von Debian und abgeleiteten Distributionen haben der Version Vixie cron 3.0pl1 veröffentlicht. Es gibt keine Unterschiede in der Syntax der Tabellendateien, für die Benutzer ist es derselbe Vixie cron. Die größten neuen Funktionen: Unterstützung für , und .
Von den weniger auffälligen, aber greifbaren Änderungen sind der Standort der Konfigurationsdateien und der Aufgabentabellen betroffen.
Benutzertabellen in Debian befinden sich im Verzeichnis \/var\/spool\/cron\/crontabs, die Systemtabelle ebenfalls im \/etc\/crontab. Paket-spezifische Aufgabentabellen von Debian werden in \/etc\/cron.d abgelegt, von wo der cron-Daemon sie automatisch einliest. Der Benutzerzugriff wird durch die Dateien \/etc\/cron.allow und \/etc\/cron.deny geregelt.
Die Standard-Shell ist nach wie vor \/bin\/sh, dessen Rolle in Debian eine kleine POSIX-konforme Shell , die ohne das Lesen von Konfigurationen (im nicht-interaktiven Modus) gestartet wird.
Der Cron-Dienst wird in den neuesten Debian-Versionen über systemd gestartet, und die Startkonfiguration kann in /lib/systemd/system/cron.service eingesehen werden. In der Dienstkonfiguration gibt es nichts Besonderes, eine detailliertere Aufgabenverwaltung kann durch Umgebungsvariablen, die direkt im Crontab jedes Benutzers deklariert sind, erfolgen.
cronie in RedHat, Fedora und CentOS
— ein Fork von Vixie Cron Version 4.1. Wie in Debian wurde die Syntax beibehalten, jedoch wurde Unterstützung für PAM und SELinux sowie Clusterbetrieb, Dateibeobachtung mit inotify und andere Funktionen hinzugefügt.
Die Standardkonfiguration befindet sich an üblichen Orten: die Systemtabelle — in /etc/crontab, Pakete legen ihre Tabellen in /etc/cron.d ab, Benutzertabellen finden sich in /var/spool/cron/crontabs.
Der Daemon wird unter der Kontrolle von systemd ausgeführt, die Dienstkonfiguration ist — /lib/systemd/system/crond.service.
In Red Hat-ähnlichen Distributionen wird standardmäßig /bin/sh verwendet, dessen Rolle dem Standard-Bash entspricht. Es ist zu beachten, dass beim Start von Cron-Aufgaben über /bin/sh die Bash-Shell im POSIX-kompatiblen Modus gestartet wird und keine zusätzliche Konfiguration liest, da sie im nicht-interaktiven Modus arbeitet.
cronie in SLES und openSUSE
Die deutsche Distribution SLES und ihr Derivat openSUSE verwenden ebenfalls cronie. Der Daemon wird hier ebenfalls unter systemd gestartet, die Dienstkonfiguration liegt in /usr/lib/systemd/system/cron.service. Konfiguration: /etc/crontab, /etc/cron.d, /var/spool/cron/tabs. Als /bin/sh fungiert dasselbe Bash, das im POSIX-kompatiblen nicht-interaktiven Modus ausgeführt wird.
Struktur von Vixie cron
Moderne Nachkommen von Cron haben sich im Vergleich zu Vixie Cron nicht radikal verändert, haben jedoch neue Möglichkeiten erworben, die nicht zur Verständigung mit den Funktionsprinzipien des Programms notwendig sind. Viele dieser Erweiterungen sind unordentlich gestaltet und verwirren den Code. Der originale Quellcode von Cron in Paul Vixies Ausführung ist eine Freude zu lesen.
Deshalb habe ich beschlossen, die Funktionsweise von Cron anhand des gemeinsamen Beispiels beider Entwicklungslinien von Cron — Vixie Cron 3.0pl1 — zu erläutern. Ich werde die Beispiele vereinfachen, indem ich komplizierte ifdef-Anweisungen weglasse und nebensächliche Details auslasse.
Die Arbeit des Daemons lässt sich in mehrere Phasen unterteilen:
- Initialisierung des Programms.
- Sammlung und Aktualisierung der Liste der auszuführenden Aufgaben.
- Ausführung des Hauptzyklus von Cron.
- Aufruf der Aufgabe.
Lassen Sie uns diese der Reihe nach betrachten.
Initialisierung
Beim Start nach der Überprüfung der Prozessargumente stellt der Cron-Prozess die Signalhandler SIGCHLD und SIGHUP ein. Der erste protokolliert das Ende des Kindprozesses, der zweite schließt den Dateideskriptor der Protokolldatei:
signal(SIGCHLD, sigchld_handler);
signal(SIGHUP, sighup_handler);Der Cron-Daemon im System läuft immer allein, nur als Superbenutzer und aus dem Hauptverzeichnis von Cron. Die folgenden Aufrufe erstellen eine Lock-Datei mit der PID des Daemon-Prozesses, stellen sicher, dass der Benutzer korrekt ist, und ändern das aktuelle Verzeichnis auf das Hauptverzeichnis:
acquire_daemonlock(0);
set_cron_uid();
set_cron_cwd();Es wird ein Standardpfad festgelegt, der bei der Ausführung von Prozessen verwendet wird:
setenv("PATH", _PATH_DEFPATH, 1);Dann wird der Prozess "daemonisiert": Er erstellt eine Kindkopie des Prozesses durch einen Fork-Aufruf und eine neue Sitzung im Kindprozess (Aufruf von setsid). Im Elternprozess besteht kein Bedarf mehr — und er beendet seine Ausführung:
switch (fork()) {
case -1:
\/\* kritischer Fehler und Beendigung \*\/
exit(0);
break;
case 0:
\/\* Kindprozess \*\/
(void) setsid();
break;
default:
\/\* Elternprozess beendet seine Ausführung \*\/
_exit(0);
}
Das Beenden des Elternprozesses gibt die Sperre in der Lock-Datei frei. Außerdem muss die PID in der Datei durch die des Kindprozesses aktualisiert werden. Danach wird die Aufgabenbasis gefüllt:
/* повторный захват лока */
acquire_daemonlock(0);
/* Заполнение БД */
database.head = NULL;
database.tail = NULL;
database.mtime = (time_t) 0;
load_database(&database);Dann geht Cron in die Hauptarbeitsphase über. Doch zuvor sollte man sich die Ladung der Aufgabenliste ansehen.
Sammlung und Aktualisierung der Aufgabenliste
Die Funktion load_database ist für das Laden der Aufgabenliste verantwortlich. Sie prüft den Hauptsystem-Crontab und das Verzeichnis mit den Benutzerdateien. Wenn sich die Dateien und das Verzeichnis nicht geändert haben, wird die Aufgabenliste nicht neu geladen. Andernfalls wird eine neue Aufgabenliste erstellt.
Laden der Systemdatei mit speziellen Dateinamen und der Tabelle:
/* если файл системной таблицы изменился, перечитываем */
if (syscron_stat.st_mtime) {
process_crontab("root", "*system*",
SYSCRONTAB, &syscron_stat,
&new_db, old_db);
}Laden der Benutzertabellen in einer Schleife:
while (NULL != (dp = readdir(dir))) {
char fname[MAXNAMLEN+1],
tabname[MAXNAMLEN+1];
\/\* Dateien mit Punkt müssen nicht gelesen werden \*\/
if (dp->d_name[0] == '.')
continue;
(void) strcpy(fname, dp->d_name);
sprintf(tabname, CRON_TAB(fname));
process_crontab(fname, fname, tabname,
&statbuf, &new_db, old_db);
}
Daraufhin wird die alte Datenbank durch die neue ersetzt.
In den obigen Beispielen stellt der Aufruf der Funktion process_crontab sicher, dass der Benutzer existiert, dessen Name zur Dateitabelle passt (es sei denn, es handelt sich um einen Superbenutzer), bevor er load_user aufruft. Letztere liest die Datei dann zeilenweise ein:
while ((status = load_env(envstr, file)) >= OK) {
switch (status) {
case ERR:
free_user(u);
u = NULL;
goto done;
case FALSE:
e = load_entry(file, NULL, pw, envp);
if (e) {
e->next = u->crontab;
u->crontab = e;
}
break;
case TRUE:
envp = env_set(envp, envstr);
break;
}
}Hier wird entweder eine Umgebungsvariable (Strings vom Typ VAR=value) mit den Funktionen load_env / env_set gesetzt oder eine Aufgabenbeschreibung (* * * * * /path/to/exec) mit der Funktion load_entry gelesen.
Das Objekt entry, das load_entry zurückgibt, ist unsere Aufgabe, die in die allgemeine Liste der Aufgaben eingefügt wird. In der Funktion findet eine umfangreiche Analyse des Zeitformats statt, uns interessiert hauptsächlich die Bildung der Umgebungsvariablen und der Startparameter der Aufgabe:
/* пользователь и группа для запуска задачи берутся из passwd*/
e->uid = pw->pw_uid;
e->gid = pw->pw_gid;
/* шелл по умолчанию (/bin/sh), если пользователь не указал другое */
e->envp = env_copy(envp);
if (!env_get("SHELL", e->envp)) {
sprintf(envstr, "SHELL=%s", _PATH_BSHELL);
e->envp = env_set(e->envp, envstr);
}
/* домашняя директория */
if (!env_get("HOME", e->envp)) {
sprintf(envstr, "HOME=%s", pw->pw_dir);
e->envp = env_set(e->envp, envstr);
}
/* путь для поиска программ */
if (!env_get("PATH", e->envp)) {
sprintf(envstr, "PATH=%s", _PATH_DEFPATH);
e->envp = env_set(e->envp, envstr);
}
/* имя пользовтеля всегда из passwd */
sprintf(envstr, "%s=%s", "LOGNAME", pw->pw_name);
e->envp = env_set(e->envp, envstr);Mit der aktuellen Aufgabenliste arbeitet die Hauptschleife.
Die Hauptschleife
Der originale cron aus Version 7 Unix arbeitete ganz einfach: Er las die Konfiguration in einer Schleife neu ein, startete die Aufgaben der aktuellen Minute als Superuser und schlief bis zum Beginn der nächsten Minute. Dieser einfache Ansatz erforderte auf alten Maschinen zu viele Ressourcen.
In SysV wurde eine alternative Version vorgeschlagen, in der der Daemon entweder bis zur nächsten Minute Schlafen ging, für die eine Aufgabe definiert ist, oder für 30 Minuten. In diesem Modus benötigte man weniger Ressourcen für das Neulesen der Konfiguration und das Überprüfen der Aufgaben, aber es wurde unpraktisch, die Aufgabenliste schnell zu aktualisieren.
Vixie cron kehrte zur Überprüfung der Aufgabenlisten einmal pro Minute zurück, da gegen Ende der 80er Jahre die Ressourcen auf standardmäßigen Unix-Maschinen deutlich mehr wurden:
/* первичная загрузка задач */
load_database(&database);
/* запустить задачи, поставленные к выполнению после перезагрузки системы */
run_reboot_jobs(&database);
/* сделать TargetTime началом ближайшей минуты */
cron_sync();
while (TRUE) {
/* выполнить задачи, после чего спать до TargetTime с поправкой на время, потраченное на задачи */
cron_sleep();
/* перечитать конфигурацию */
load_database(&database);
/* собрать задачи для данной минуты */
cron_tick(&database);
/* перевести TargetTime на начало следующей минуты */
TargetTime += 60;
}
Die Ausführung der Aufgaben erfolgt durch die Funktion cron_sleep, die die Funktionen job_runqueue (Durchlauf und Start der Aufgaben) und do_command (Start jeder einzelnen Aufgabe) aufruft. Letztere Funktion sollte genauer betrachtet werden.
Aufgabe starten
Die Funktion do_command ist im guten Unix-Stil implementiert, das heißt, für die asynchrone Ausführung einer Aufgabe wird ein Fork durchgeführt. Der Elternprozess startet weiterhin Aufgaben, der Kindprozess kümmert sich um die Vorbereitung des Aufgabensatzes:
switch (fork()) {
case -1:
/*konnte keinen fork ausführen */
break;
case 0:
/* Kindprozess: versuchen wir zur Sicherheit erneut, das Hauptschloss zu bekommen */
acquire_daemonlock(1);
/* wir gehen zur Erstellung des Aufgabenprozesses über */
child_process(e, u);
/* nach Beendigung beendet der Kindprozess die Arbeit */
_exit(OK_EXIT);
break;
default:
/* der Elternprozess arbeitet weiter */
break;
}In child_process gibt es eine Menge Logik: Sie übernimmt die Standardausgaben und Fehler, um sie später per E-Mail weiterzuleiten (wenn in der Aufgabenstabelle die Umgebungsvariable MAILTO angegeben ist), und wartet schließlich auf den Abschluss des Hauptprozesses der Aufgabe.
Der Aufgabenprozess wird durch einen weiteren Fork gebildet:
switch (vfork()) {
case -1:
exit(ERROR_EXIT);
case 0:
(void) setsid();
setgid(e->gid);
setuid(e->uid);
chdir(env_get("HOME", e->envp));
{
char *shell = env_get("SHELL", e->envp);
execle(shell, shell, "-c", e->cmd, (char *)0, e->envp);
perror("execl");
_exit(ERROR_EXIT);
}
break;
default:
break;
}So sieht im Grunde der gesamte cron aus. Einige interessante Details, wie die Berücksichtigung von entfernten Benutzern, habe ich ausgelassen, aber das Wesentliche habe ich dargestellt.
Nachwort
Cron ist ein überraschend einfaches und nützliches Programm, das nach besten Traditionen der Unix-Welt ausgeführt wird. Es tut nichts Überflüssiges, erfüllt jedoch seine Aufgabe seit Jahrzehnten hervorragend. Das Kennenlernen des Codes der Version, die mit Ubuntu geliefert wird, hat nicht einmal eine Stunde gedauert, und ich hatte viel Freude daran! Ich hoffe, ich konnte diese Freude mit Ihnen teilen.
Ich weiß nicht, wie es Ihnen geht, aber es macht mich etwas traurig zu erkennen, dass modernes Programmieren mit seiner Neigung zur Überkomplexität und Überabstraktion inzwischen weit von einer solchen Einfachheit entfernt ist.
Es gibt viele moderne Alternativen zu cron: systemd-timer ermöglichen die Organisation komplexer Systeme mit Abhängigkeiten, während fcron eine flexiblere Regulierung des Ressourcenverbrauchs durch Aufgaben zulässt. Aber persönlich hat mir immer der einfachste crontab gereicht.
Kurz gesagt, lieben Sie Unix, verwenden Sie einfache Programme und vergessen Sie nicht, die Manpages für Ihre Plattform zu lesen!
Quelle: habr.com
