Die Datei factory.ini, Abschnitt [spooler]
Die Einträge
log=dateiname
|
Dateiname des Protokolls scheduler.log |
Wenn diese Einstellung gesetzt ist, schreibt der Job Scheduler ein detailliertes Protokoll zur Fehlerdiagnose in die Datei. Geben Sie den Dateinamen absolut an (als vollständigen Pfad).
Ein Plus (+) direkt vor dem Dateinamen lässt ein vorhandenenes Protokoll fortsetzen. Sonst wird es überschrieben.
Kategorien
Sie können das Protokoll mit Kategorien erweitern oder einschränken. Schreiben Sie die Namen der Kategorien mit Zwischenräumen getrennt vor den Dateinamen, den Sie mit einem Größerzeichen (>) einleiten.
Hier ist die Liste der Kategorien.
| Die Option |
-log
|
hat Vorrang |
Beispiel
log = c:/tmp/scheduler.log
log = scheduler.wait >scheduler.log
log = scheduler.wait com_server.* >scheduler.log
id=scheduler_id
|
Kennung des Job Schedulers |
Der Job Scheduler wählt nur die Elemente der XML-Konfiguration aus, deren Attribut spooler_id leer ist oder denselben Wert wie in dieser Einstellung enthält.
Wenn die Scheduler-ID nicht angegeben ist, beachtet der Job Scheduler das XML-Attribut spooler_id= nicht und wählt alle Elemente der XML-Konfiguration aus.
Siehe z.B. <config>.
| Die Eigenschaft |
Spooler.id |
liest die Einstellung |
| Die Option |
-id
|
hat Vorrang |
config=dateiname
|
Konfigurationsdatei |
log_dir=verzeichnis
|
Verzeichnis der Protokolle |
In dieses Verzeichnis schreibt der Job Scheduler seine Protokolle.
log_dir=*stderr lässt den Job Scheduler die Protokollausgabe nach stderr (auf den Bildschirm) schreiben.
Umgebungsvariablen (z.B. $HOME) werden ersetzt (siehe hier).
log_level=log_level
|
(Initialwert: info) Protokollausgaben beschränken
|
Legt fest, ab welcher Stufe der Job Scheduler Protokollzeilen ausgibt. Jede Protokollzeile ist auf einer der folgenden Stufen: error, warn, info, debug1 bis debug9 (debug1 ist dasselbe wie debug).
param=text
|
Zur freien Verwendung |
Zur freien Verwendung. Der Parameter ist in den Skripten über spooler.param lesbar.
include_path=verzeichnis
|
Verzeichnispfad für <include> |
Verzeichnis der Dateien, die mit <include> eingezogen werden.
Umgebungsvariablen (z.B. $HOME) werden ersetzt (siehe hier).
html_dir=verzeichnis
|
Verzeichnis der HTML-Dateien |
In diesem Verzeichnis stehen die HTML-Dateien für den HTTP-Server im Job Scheduler.
Wenn die Angabe fehlt, nimmt der Job Scheduler das Verzeichnis html im Verzeichnis der Konfigurationsdatei.
Umgebungsvariablen (z.B. $HOME) werden ersetzt (siehe hier).
history=yes|no
|
(Initialwert: yes) Historie schreiben?
|
Gibt an, ob eine Task-Historie geschrieben werden soll. Der Job Scheduler schreibt dann für jede Task einen Satz in die Datenbank, oder, wenn der Job Scheduler ohne Datenbank arbeitet, in eine Datei im mit -log-dir angegebenen Verzeichnis.
db=verbindungszeichenfolge
|
Verbindungszeichenfolge der Datenbank |
Verbindungszeichenfolge der Datenbank für die Historienführung. Der Job Scheduler unterstützt ODBC (Windows) und JDBC für den Zugriff auf Datenbanken. Ohne Eintrag werden Dateien im .csv-Format erzeugt, siehe factory.ini (Abschnitt [spooler], Eintrag history_file=…).
Unter Windows kann ein einfacher Dateiname angegebenen werden, der auf .mdb endet (z.B. scheduler.mdb). Der Job Scheduler verwendet dann eine Microsoft MS-Access Datenbank dieses Namens, die im Protokollverzeichnis (s. Option -log-dir) liegt. Der Job Scheduler richtet die Datei ein, wenn sie fehlt.
Der Job Scheduler richtet die Tabellen selbständig ein.
Beispiel
; SQL Server 2000 via msbase.jar, msutil.jar, mssqlserver.jar
db = jdbc -class=com.microsoft.jdbc.sqlserver.SQLServerDriver jdbc:microsoft:sqlserver://localhost:1433;selectMethod=Cursor;databaseName=scheduler -user=scheduler -password=secret
; SQL Server 2000, 2005 via sqljdbc.jar
db = jdbc -class=com.microsoft.sqlserver.jdbc.SQLServerDriver jdbc:sqlserver://localhost:1433;sendStringParametersAsUnicode=false;selectMethod=cursor;databaseName=scheduler -user=scheduler -password=secret
; MySQL 4.1.7, 5.x
db = jdbc -class=com.mysql.jdbc.Driver jdbc:mysql://localhost/scheduler:3306 -user=scheduler -password=secret
; Oracle 8.1.7, 9i, 10g
db = jdbc -class=oracle.jdbc.driver.OracleDriver jdbc:oracle:thin:@localhost:1521:orcl -user=scheduler -password=secret
; PostgreSQL 8.x
db = jdbc -class=org.postgresql.Driver jdbc:postgresql://localhost:5432/scheduler -user=scheduler -password=secret
; IBM DB2 8
db = jdbc -class=com.ibm.db2.jcc.DB2Driver jdbc:db2://localhost:50000/scheduler:driverType=2;retrieveMessagesFromServerOnGetMessage=true; -user=scheduler -password=secret
; Firebird 1.5
db = jdbc -class=org.firebirdsql.jdbc.FBDriver jdbc:firebirdsql://localhost:3050/scheduler -user=scheduler -password=secret
; ODBC
db = odbc -db=scheduler_datasource -user=scheduler -password=secret
; MS Access Datenbank
db = scheduler.mdb
need_db=yes|no|strict
|
(Initialwert: no) Ist die Datenbank notwendig?
|
need_db=no -
Wenn die Einstellung db= fehlt, gibt der Job Scheduler eine Warnung aus und arbeitet ohne Datenbank.
Wenn das Öffnen der Datenbank oder das automatische Anlegen der Tabellen fehlschlägt, gibt der Job Scheduler eine Warnung aus und arbeitet ohne Datenbank.
Bei einem Datenbankfehler während des Betriebs schließt der Job Scheduler die Datenbank und öffnet sie erneut. Wenn das fehlschlägt, arbeitet der Job Scheduler ohne Datenbank weiter.
Im Cluster-Betrieb (-exclusive oder -distributed-orders) lehnt der Job Scheduler need_db=no ab mit der Meldung:
SCHEDULER-358 |
This is a member of a cluster (option -exclusive or -distributed-orders), and therefore needs a database. need_db=(1) is not allowed |
need_db=yes -
Wenn die Einstellung db= fehlt, startet der Job Scheduler nicht und gibt die Meldung SCHEDULER-205 aus.
Bei einem Datenbankfehler schließt der Job Scheduler die Datenbank und öffnet sie erneut. Wenn das fehlschlägt, versucht der Job Scheduler endlos im Abstand von einer Minute die Datenbank erneut zu öffnen. Die Tasks werden währenddessen nicht bedient.
Wenn sich die Datenbank nicht erneut öffnen lässt, schickt er eine eMail.
need_db=strict -
Wie need_db=yes mit folgender Ausnahme.
Bei einem Datenbankfehler während des Betriebs schließt der Job Scheduler die Datenbank und öffnet sie erneut. Bei einem erneuten Fehler wiederholt der Scheduler den Versuch so oft, wie mit max_db_errors= eingestellt. Wenn das fehlschlägt, beendet sich der Scheduler.
db_variables_table=name
|
(Initialwert: SCHEDULER_VARIABLES) Name der Datenbanktabelle für die internen Variablen des Job Schedulers
|
Der Job Scheduler hält in dieser Tabelle interne Zähler, zum Beispiel für die nächste freie Task-ID.
db_tasks_table=name
|
(Initialwert: SCHEDULER_TASKS) Name der Datenbanktabelle für die Tasks
|
db_orders_table=name
|
(Initialwert: SCHEDULER_ORDERS) Name der Datenbanktabelle für die Aufträge
|
db_history_table=name
|
(Initialwert: SCHEDULER_HISTORY) Name der Datenbanktabelle für die Historie
|
db_order_history_table=name
|
(Initialwert: SCHEDULER_ORDER_HISTORY) Name der Datenbanktabelle für die Auftragshistorie
|
db_order_step_history_table=name
|
(Initialwert: SCHEDULER_ORDER_STEP_HISTORY) Name der Datenbanktabelle für die Schritte der Auftragshistorie
|
db_check_integrity=yes|no
|
|
Der Scheduler führt zusätzliche Prüfungen der Datenbank-Integrität durch.
max_db_errors=zahl
|
(Initialwert: 5) Anzahl Datenbank-Fehler, bevor Job Scheduler aufgibt
|
Der Job Scheduler toleriert diese Anzahl Datenbankfehler. Wird sie überschritten, dann setzt er bei need_db=no ohne Datenbank fort, anderfalls beendet er sich sofort.
Bei need_db=yes werden Fehler, die beim Versuch, die Datenbank zu öffnen, auftreten, nicht gezählt. Damit kann er Job Scheduler auf eine Datenbank warten, die noch nicht angelaufen ist.
history_file=dateiname
|
Dateiname der Historie (für datenbanklosen Betrieb) |
Der Job Scheduler nimmt einen eigenen Namen, wenn diese Option fehlt. Die Option -log-dir muss gesetzt sein - andernfalls schreibt der Job Scheduler die Datei nicht. In diese Datei wird, wenn die Option history=yes gesetzt ist und der Job Scheduler keine Datenbank verwendet, für jede abgelaufene Task ein Satz geschrieben.
history_columns=name, name, ...
|
Zusätzliche Spalten in der Historie |
Eine Task kann mit der Methode Task.set_history_field() die hier angegebenen Felder der Datenbanktabelle für die Task-Historie setzen.
history_on_process=yes|no|zahl
|
(Initialwert: 0) Nach spooler_process() Historiensatz schreiben?
|
Bei history_on_process=no oder =0 schreibt der Job Scheduler beim Start der Task einen Satz in die Historie, wenn eine geführt wird.
Bei history_on_process=yes oder =1 schreibt der Job Scheduler erst beim ersten Aufruf von spooler_process() den Satz. Damit wird kein Satz geschrieben, wenn spooler_open() false liefert.
Wenn eine Zahl angegeben ist, schreibt der Job Scheduler erst vor der angegebenen Anzahl von Aufrufen von spooler_process() einen Satz in die Historie.
Meldungen
[ERROR] |
SCHEDULER-335 |
Only "yes", "no" and a number are allowed with (1) ="(2) ": error(3)
|
history_archive=yes|no|gzip
|
(Initialwert: no) Historiendateien archivieren?
|
Wenn die Historie in einer Datei, d.h. nicht in einer Datenbank, geführt wird, kann der Job Scheduler die Historien des letzten Job Scheduler Laufs archivieren und mit gzip komprimieren.
history_with_log=yes|no|gzip
|
(Initialwert: no) Protokoll in die Historie schreiben?
|
Der Job Scheduler kann das Task-Protokoll in die Historie in der Datenbank schreiben, auch mit gzip komprimiert.
Siehe Kommando <show_task what="log">.
order_history=yes_no
|
(Initialwert: yes) Aufträge in die Historie schreiben?
|
Für die Aufträge gibt es eine eigene Historie.
order_history_with_log=yes|no|gzip
|
(Initialwert: no) Auftragsprotokolle in die Historie schreiben?
|
Der Job Scheduler kann das Auftragsprotokoll in die Datenbank schreiben, auch mit gzip komprimiert.
Siehe Kommando <show_order what="log">.
subprocess.own_process_group=yes|no
|
(Initialwert: no) Subprozesse in eigener Prozessgruppe starten
|
smtp=host_address
|
Hostname oder IP-Nummer des SMTP-Servers für eMail Versand |
log_mail_subject=text
|
Betreff der eMails |
log_mail_from=email_address
|
Absender der eMails |
log_mail_to=email_address
|
To-Empfänger der eMails |
log_mail_cc=email_address
|
Cc-Empfänger der eMails |
log_mail_bcc=email_address
|
Bcc-Empfänger der eMails |
mail_queue_only=yes|no
|
eMail nicht versenden, nur in die eMail-Warteschlange hängen |
mail_on_error=yes|no
|
(Initialwert: no) Mit Fehler beendete Task verschickt eMail
|
mail_on_warning=yes|no
|
(Initialwert: no) Wenn eine Warnung oder ein Fehler ausgegeben worden ist, wird am Task-Ende eine eMail verschickt
|
mail_on_process=yes|no|zahl
|
(Initialwert: 0) Task mit spooler_process() verschickt eMail
|
Veranlasst den Versand des Task-Protokolls, wenn die Task wenigstens die angegebene Anzahl Schritte, also Aufrufe von spooler_process(), ausgeführt hat. Weil Nicht-API-Tasks keine Schritte haben, zählt der Scheduler für sie immer einen Schritt.
yes entspricht 1, no entspricht 0.
mail_on_success=yes|no
|
(Initialwert: no) Erfolgreich gelaufende Task verschickt eMail
|
mail_on_delay_after_error=
|
(Initialwert: first_and_last_only) Unterdrückung der eMail bei <delay_after_error>
|
Voraussetzung: mail_on_error=yes oder mail_on_warning=yes
Wenn ein Job wegen <delay_after_error> erneut startet, werden mit dieser Einstellungen die zahlreichen eMails reduziert.
-
mail_on_delay_after_error=all - Nach jedem fehlerhaften Job-Lauf wird eine eMail verschickt.
-
mail_on_delay_after_error=first_only - Nur der erste fehlerhafte Lauf veranlasst eine eMail, nicht aber die Wiederholungen.
-
mail_on_delay_after_error=last_only - Nur der letzte fehlerhafte Lauf, der also den Job stoppen lässt, veranlasst eine eMail.
-
mail_on_delay_after_error=first_and_last_only - Nur der erste und der letzte fehlerhafte Lauf veranlassen je eine eMail.
Die Einstellung wirkt nicht, wenn für den Job kein <delay_after_error> angegeben ist (dann gilt mail_on_delay_after_error=all).
mail_queue_dir=verzeichnis
|
Verzeichnis der zeitweilig nicht versendbaren eMails |
eMails, die der Job Scheduler nicht verschicken kann (weil z.B. der SMTP-Server nicht erreichbar ist), werden hier abgelegt.
Um diese eMails später zu verschicken, muss ein Job geschrieben werden, der die Methode Mail.dequeue() aufruft.
Der allgemeine Platz für diese Einstellung ist sos.ini (Abschnitt [mail], Eintrag queue_dir=…).
Umgebungsvariablen (z.B. $HOME) werden ersetzt (siehe hier).
tmp=path
|
Verzeichnis der temporären Dateien |
Voreinstellung ist die Umgebungsvariable TMP, unter Windows auch TEMP.
Unter Unix wird /tmp/ verwendet, wenn die Umgebungsvariable nicht gesetzt ist.