XML-Element  <job>     (Konfiguration)

Das Element ist nur wirksam, wenn dieses Attribut gleich dem Parameter -id= vom Scheduler-Start ist, oder wenn beim Scheduler-Start der Parameter -id= nicht angegeben worden ist.

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 Job.order_queue das Attribut prüfen.

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

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

<lock.use>: 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.

<job tasks="…"> muss groß genug sein.

Der Scheduler startet weitere Tasks, wenn

• der Scheduler startet
• oder eine Task sich beendet hat
• oder eine neue Periode (<run_time>) beginnt
• oder bei <modify_job cmd="unstop">: der Job wird entstoppt
• oder bei <modify_job cmd="continue">: alle Tasks des Jobs werden fortgesetzt
• oder bei <modify_job cmd="wake">: der Job wird geweckt

• und weniger Tasks laufen als mit min_tasks verlangt
• und die <run_time> 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:

• spooler_process() wurde aufgerufen.
• Die Task wartete eine Zeitlang auf einen Auftrag (Zustand running_waiting_for_order, nicht wenn <job idle_timeout="0">).
• Die Task startete, wurde aber mit Task.delay_spooler_process verzögert.
• Die Task ist ein Prozess (<process> oder <script language="shell">) und der Prozess hat sich nicht sofort nach Start beendet.

Meldungen

Befristet eine Task-Operation (spooler_open, spooler_process etc.) oder bei einer Nicht-API-Task (<process> oder <script language="shell">) 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 <run_time>.

Siehe auch <job force_idle_timeout="…">.

Nur wirksam mit <job min_tasks ≥ "0"> und <job idle_timeout="…">.

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 Task.priority_class.

Bei temporary="yes" ist der Job temporär. Nur für <add_jobs>. 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. <process_classes>) und der Job oder der Monitor in Java implementiert ist. Die Optionen werden zusammen mit den Optionen aus <config java_options="…"> Java übergeben. Wie gleichnamige Optionen interpretiert werden, hängt von Java ab.

visible="no" und visible="never" lassen den Job im Ergebnis von <show_jobs> und <show_state> 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 SCHEDULER-279).

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 SCHEDULER-974 darauf hin.

Siehe auch <commands on_exit_code="SIGTERM"> und das Gnu-Kommando man 7 signal.

Meldungen

Beispiel  

<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 spooler_log.error() geschrieben werden.

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

Die Einstellung hat keine Wirkung, wenn <delay_after_error> oder Job.delay_after_error verwendet wird.

Meldungen

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 (<job order="yes">) kann nicht ersetzt werden.

Wenn ein Jobschritt vor der angegebenen Zeit beendet wird, gibt der Scheduler die Warnung SCHEDULER-711 aus.

Die Zeit kann im den Formaten HH:MM, HH:MM:SS, als Sekundenzahl oder als Prozentangabe angegeben werden. Dabei sind 100% die durchschnittliche Laufzeit der bisherigen Jobschritte, ermittelt aus der Datenbanktabelle SCHEDULER_HISTORY.

Wenn ein Jobschritt länger als die angegebenen Zeit dauert, gibt der Scheduler die Warnung SCHEDULER-711 aus.

Die Zeit kann im den Formaten HH:MM, HH:MM:SS, als Sekundenzahl oder als Prozentangabe angegeben werden. Dabei sind 100% die durchschnittliche Laufzeit der bisherigen Jobschritte, ermittelt aus der Datenbanktabelle SCHEDULER_HISTORY.

<lock.use> kann wiederholt werden.

<start_when_directory_changed> kann wiederholt werden.

<delay_after_error> kann wiederholt werden.

<delay_order_after_setback> kann wiederholt werden.

<commands> kann wiederholt werden.