Every PDS job starts a launcher script. The output of this script and its sub processes is stored in files and fetched and persisted when the job has failed or succeeded.
An administrator is able to fetch the persisted output for each dedicated job.
Problem
When it comes to problems - e.g. on a wrapper application which is used by the script - it is not possible to just look into the PDS logfile to get the information but you always need to retrieve the information from database / via REST.
Wanted
It shall be possible to define at runtime, if the logs from launcher script and its subprocesses is added to the normal PDS log file.
Solution
We introduce a new PDS parameter key for this. When not defined in executor configuration the initial default will be false.
When enabled, the PDS will read system-out.log and system-error.log before the workspace cleanup is done (no matter if failed or succeeded). Each line will be logged by logger.
Situation
Every PDS job starts a launcher script. The output of this script and its sub processes is stored in files and fetched and persisted when the job has failed or succeeded.
An administrator is able to fetch the persisted output for each dedicated job.
Problem
When it comes to problems - e.g. on a wrapper application which is used by the script - it is not possible to just look into the PDS logfile to get the information but you always need to retrieve the information from database / via REST.
Wanted
It shall be possible to define at runtime, if the logs from launcher script and its subprocesses is added to the normal PDS log file.
Solution
We introduce a new PDS parameter key for this. When not defined in executor configuration the initial default will be false.
When enabled, the PDS will read system-out.log and system-error.log before the workspace cleanup is done (no matter if failed or succeeded). Each line will be logged by logger.