Jeder Job hat einen eigenen Namen.

Wenn ein Job mit demselben Namen in einer Basiskonfiguration bereit definiert worden ist, können hier die Einstellungen des Jobs geändert oder ergänzt werden.

Eine einzeilige Beschreibung des Jobs.

Bei order="yes" ist der Job auftragsgesteuert. Der Scheduler startet diesen Job nur, wenn ein Auftrag vorliegt.

Ein Skript kann mit das Attribut prüfen.

Gibt den Namen der Prozessklasse an, in der Tasks dieses Jobs laufen sollen. Die Prozessklassen werden mit definiert.

Von einem Job können mehrere Tasks gleichzeitig laufen. Dieses Attribut begrenzt deren Anzahl.

: Zusammen mit einer exklusiven Sperre ist nur tasks="1" sinnvoll, sie erlaubt nur eine Task.

Der Scheduler sorgt dafür, das wenigstens die angegebene Anzahl Tasks läuft. So lassen sich auftragsgesteuerte Tasks in Bereitschaft bringen, die sehr lange für ihre Initialisierung brauchen.

muss groß genug sein.

Der Scheduler startet weitere Tasks, wenn

  • der Scheduler startet
  • oder eine Task sich beendet hat
  • oder eine neue Periode () beginnt
  • oder bei : der Job wird entstoppt
  • oder bei : alle Tasks des Jobs werden fortgesetzt
  • oder bei : der Job wird geweckt
  • und weniger Tasks laufen als mit min_tasks verlangt
  • und die mit einer Periode den Start zulässt
  • und der Job im Zustand pending oder running ist (also nicht gestoppt wird oder gestoppt ist).

Um ein Heißlaufen zu verhindern, startet der Scheduler keine neuen Tasks, nachdem sich eine sofort beendet hat. Nur in folgenden Fällen führt das Ende einer Task zum Start einer neuen:

  • wurde aufgerufen.
  • Die Task wartete eine Zeitlang auf einen Auftrag (Zustand running_waiting_for_order, nicht wenn ).
  • Die Task startete, wurde aber mit verzögert.
  • Die Task ist ein Prozess ( oder ) und der Prozess hat sich nicht sofort nach Start beendet.

Befristet eine Task-Operation (spooler_open, spooler_process etc.) oder bei einer Nicht-API-Task ( oder ) die ganze Task. Nach Ablauf der Frist bricht der Scheduler die Task ab.

dauer kann in Sekunden oder im Format HH:MM oder HH:MM:SS angegeben werden.

Begrenzt den Leerlauf eines auftragsgesteuerten Jobs (order="yes"). Wenn eine Task auf den nächsten Auftrag wartet und in der Frist kein Auftrag eintrifft, beendet der Scheduler sie.

dauer kann in Sekunden oder im Format HH:MM oder HH:MM:SS angegeben werden.

idle_timeout="never" lässt den Job unbegrenzt laufen, nur noch abhängig von .

Siehe auch .

Nur wirksam mit und .

force_idle_timeout="yes" beendet nach Ablauf von idle_timeout die Task, auch wenn daraufhin min_tasks unterschritten wird. Erst anschließend führt min_tasks zum Start einer neuen Task.

Damit lassen sich Tasks beenden, die im Leerlauf eine Ressource (z.B. eine Datenbank) nicht zu lange belegen dürfen, weil diese sich sonst abkoppelt.

Eingestellt können die Werte idle, below_normal, normal, above_normal und high oder die numerischen Werte des Betriebsystems.

Wenn die Priorität nicht gesetzt werden kann, führt das nicht zu einem Fehler.

Ein Prozess mit hoher Priorität kann Ihren Rechner blockieren.

Siehe .

Bei temporary="yes" ist der Job temporär. Nur für . Nach der Ausführung wird der Job gelöscht und ist dann unbekannt.

Wirkt nur, wenn der Job als eigener Prozess ausgeführt wird (s. ) und der Job oder der Monitor in Java implementiert ist. Die Optionen werden zusammen mit den Optionen aus Java übergeben. Wie gleichnamige Optionen interpretiert werden, hängt von Java ab.

visible="no" und visible="never" lassen den Job im Ergebnis von und unsichtbar.

Bei visible="no" setzt der Scheduler den Job sichtbar, sobald eine Task eingereiht wird. Bei visible="never" ist das nicht der Fall.

Wirksam nur unter Unix.

Ein Job, dessen Task-Prozess mit Signal abbricht, führt zum Stopp des Jobs. Ursache eines Signals ist ein Abbruch der Task durch das System-Kommando kill oder durch einen Programmabbruch.

Wenn ignore_signals nicht angegeben ist, stoppt eine mit Signal abbrechene Task den Job (mit Meldung ).

ignore_signals="all" lässt den Job nicht stoppen.

Statt "all" können Sie auch eine Liste von Signalnamen angeben (durch Leerzeichen getrennt). Dabei sind, abhängig vom Betriebssystem, diese Signalnamen bekannt: SIGHUP, SIGINT, SIGQUIT, SIGILL, SIGTRAP, SIGABRT, SIGIOT, SIGBUS, SIGFPE, SIGKILL, SIGUSR1, SIGSEGV, SIGUSR2, SIGPIPE, SIGALRM, SIGTERM, SIGSTKFLT, SIGCHLD, SIGCONT, SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU, SIGURG, SIGXCPU, SIGXFSZ, SIGVTALRM, SIGPROF, SIGWINCH, SIGPOLL, SIGIO, SIGPWR und SIGSYS. Signal-Namen, die das Betriebsystem nicht kennt, werden mit Warnung ignoriert.

Weil eine mit einem zu ignorierenden Signal abbrechende Task trotzdem zuerst einen TCP-Verbindungsfehler (ECONNRESET) hervorruft, führen TCP-Verbindungsfehler nur dann zum Stopp des Jobs, wenn ignore_signals="…" nicht zutrifft. Der Scheduler weist mit der Meldung darauf hin.

Siehe auch und das Gnu-Kommando man 7 signal. 

<job name="my_job" ignore_signals="SIGTERM SIGKILL">

Die Voreinstellung stop_on_error="yes" stoppt den Job, wenn eine Task mit Exception oder mit einer Fehlermeldung "[ERROR]" in ihrem Task-Protokoll endet. Eine Fehlermeldung kann z.B. mit geschrieben werden.

stop_on_error="no" lässt den Job in diesen Fällen nicht stoppen. Endet mit Exception, versetzt der Scheduler den Auftrag in den Fehlerzustand ().

Die Einstellung hat keine Wirkung, wenn oder verwendet wird.

replace="yes" lässt diese Job-Definition eine evtl. bereits vorhandene ersetzen. Wenn das nicht möglich ist, weil z.B. gerade eine Task läuft, dann ersetzt der Scheduler den Job später.

Ein auftragsgesteuerte Job () kann nicht ersetzt werden.

Definiert einen Job mit Programmcode, Laufzeit usw.