- Dienstprogramm zur Umsetzung eines leichtgewichtigen Job-Queue-Systems, das ohne separate Konfiguration oder Daemon auskommt
- Unterstützt Linux/macOS – lauffähig auf POSIX-kompatiblen Systemen mit Unterstützung für flock(2)
- Unterstützt ad-hoc queueing temporärer Jobs über die Kommandozeile
- Geeignet für sequentielle Aufgaben wie Makefile-Builds, Dateidownloads oder Benchmark-Ausführungen
- Kann auch als Alternative zu
nohup verwendet werden
- Die Reihenfolge der Jobs wird streng garantiert durch Synchronisierung auf Basis von Zeitstempeln im ms-Bereich
- Für jeden Prozess wird TIMESTAMP.PID erzeugt und mit flock (Dateisperre) gearbeitet
- Wenn die vorherigen flock-Sperren freigegeben werden, startet der nächste Job
- Da die Synchronisierung auf Dateisystemebene erfolgt, ist kein Polling erforderlich
- Fügt man einen Job in der Form
nq CMDLINE... zur Queue hinzu, wird eine Job-ID ausgegeben und der Job im Hintergrund ausgeführt
- STDOUT/STDERR werden in Logdateien umgeleitet
- Über das Ausführungs-Bit (
+x) der Logdatei lässt sich der Job-Status visuell unterscheiden
- Die Dateiendung der Logdatei besteht aus der PID, was die Job-Verwaltung erleichtert
- Vor der Ausführung ist es die PID von
nq, danach wird sie auf die tatsächliche Job-PID geändert
- Die Logdatei kann wie ein Shell-Skript ausgeführt werden, um den Job erneut zu starten
Unterschiede zu at, batch, task-spooler
at
Ein Tool, das Jobs zu einer festgelegten Zeit ausführt
Es führt Befehle zu einem anhand der Systemuhr geplanten Zeitpunkt aus und wird vor allem für einmalige geplante Aufgaben verwendetbatch
Führt Jobs aus, wenn die Systemlast (load average) niedrig ist
Ziel ist nicht die Terminplanung, sondern lastbasierte Steuerung der Ausführung; verwaltet wird dies durch einen Daemontask-spooler
Startet automatisch einen Daemon zur Queue-Verwaltung und unterstützt sequentielle oder parallele Job-Verarbeitung
Es kann die maximale Anzahl gleichzeitig laufender Jobs festgelegt werden
Für jedes Terminal lassen sich unterschiedliche Queues konfigurieren, und der Status jeder Queue kann per Befehl abgefragt werdennq
Funktioniert ohne Daemon und verwaltet die Queue ausschließlich über Dateisystem-Sperren (flock) auf Verzeichnisebene
Ohne Berücksichtigung von Systemlast oder geplanten Zeitpunkten garantiert es schlicht die Reihenfolge der Jobs
Die Logs der Queue lassen sich mit nqtail in Echtzeit verfolgen
Da jedes Verzeichnis als unabhängige Queue fungiert, können mit der Umgebungsvariable $NQDIR mehrere Queues getrennt betrieben werden
2 Kommentare
Der Codestil ist so sehr alter Sourceforge-Stil, dass ich dachte, ich wäre in die Vergangenheit zurückgekehrt, haha.
Verglichen mit den SourceForge-Zeiten bin ich zwar noch ein blutjunger Entwickler, aber ich dachte erst: Was soll das heißen? Als ich dann den Zeilenumbruch zwischen Funktions-Rückgabetyp und Namen gesehen habe, war ich sofort überzeugt. o.o
Gibt es in diesem Code vielleicht noch andere altmodische Coding-Stile, die auffallen?