Das bemängelte Verhalten ist so vorgesehen.
Ein Auftrag, der durch einen Shell-Job geht, bekommt bislang immer den next_state, weil der Job ja kein spooler_process() mit return false kennt. Das können wir natürlich ändern. Bei einem exit_code ungleich 0 könnte der Auftrag in den error_state gehen. Dazu sollte der Job aber nicht gestoppt werden (stop_on_error="no" oder ignore_error="yes"). Gleiches bei einem Signal (unter Unix), also einem Abbruch, wenn der Job wegen ignore_signal nicht stoppt.
Wenn der Job stoppt (wegen der Defaults stop_on_error="yes", ignore_error="no" und ignore_signal="no"), sollte der Auftrag an Ort und Stelle, also in der Auftragswarteschlange des Jobs bleiben, so wie das auch für API-Jobs gilt. Nach Reparatur des Stopp-Grundes kann der Job erneut gestartet , und der Ausführungsschritt des Auftrags wiederholt werden. Dasselbe gilt für <delay_after_error>.
Das derzeitige Verhalten des Schedulers, den Auftrag in den next_state zu versetzen, bevor der Stopp des Jobs erkannt wird, ist nicht korrekt.
Also:
- Kein Fehler (also auch exit_code=0): next_state
- Unterdrückter Fehler, der also nicht zum Stopp führt: error_state
- Job stoppt (oder <delay_after_error> wirkt): Auftrag bleibt in der Wartschlange
Ich denke, wir sollten es so machen. Es ist vielleicht nicht kompatibel, weshalb ich das gerne von euch bestätigt haben möchte. Sollen die Fehler vielleicht weiter differenziert, vor allem von exit_code != 0 unterschieden werden? Man könnte "gute Exit-Codes" einführen.
Grüße
Joacim Zschimmer
Bug
Closed
Major
Das bemängelte Verhalten ist so vorgesehen.
Ein Auftrag, der durch einen Shell-Job geht, bekommt bislang immer den next_state, weil der Job ja kein spooler_process() mit return false kennt. Das können wir natürlich ändern. Bei einem exit_code ungleich 0 könnte der Auftrag in den error_state gehen. Dazu sollte der Job aber nicht gestoppt werden (stop_on_error="no" oder ignore_error="yes"). Gleiches bei einem Signal (unter Unix), also einem Abbruch, wenn der Job wegen ignore_signal nicht stoppt.
Wenn der Job stoppt (wegen der Defaults stop_on_error="yes", ignore_error="no" und ignore_signal="no"), sollte der Auftrag an Ort und Stelle, also in der Auftragswarteschlange des Jobs bleiben, so wie das auch für API-Jobs gilt. Nach Reparatur des Stopp-Grundes kann der Job erneut gestartet , und der Ausführungsschritt des Auftrags wiederholt werden. Dasselbe gilt für <delay_after_error>.
Das derzeitige Verhalten des Schedulers, den Auftrag in den next_state zu versetzen, bevor der Stopp des Jobs erkannt wird, ist nicht korrekt.
Also:
Ich denke, wir sollten es so machen. Es ist vielleicht nicht kompatibel, weshalb ich das gerne von euch bestätigt haben möchte. Sollen die Fehler vielleicht weiter differenziert, vor allem von exit_code != 0 unterschieden werden? Man könnte "gute Exit-Codes" einführen.
Grüße
Joacim Zschimmer
- Kein Fehler (also auch exit_code=0): next_state
- Unterdrückter Fehler, der also nicht zum Stopp führt: error_state
- Job stoppt (oder <delay_after_error> wirkt): Auftrag bleibt in der Wartschlange
Ich denke, wir sollten es so machen. Es ist vielleicht nicht kompatibel, weshalb ich das gerne von euch bestätigt haben möchte. Sollen die Fehler vielleicht weiter differenziert, vor allem von exit_code != 0 unterschieden werden? Man könnte "gute Exit-Codes" einführen. Grüße Joacim Zschimmer