windowssignal-handlingautosysremote-process

Autosys: KILLJOB event leaves orphan processes


I am running a variety of processes on a Windows server ( a mix of batch files, java, perl, csharp scripts/applications). These processes are launched using Autosys. The autosys agent on Windows always prefixes the command I provide in the job definition with 'cmd /c' (see example below)

C:\Windows\system32\cmd.exe /C foobar.exe

This by itself is not a problem, but when I try to kill job by sending an autosys KILLJOB event (that as per Autosys documentation sends a interrupt followed by kill signal to the process), the foobar.exe is not killed, it is the parent cmd.exe that gets killed. foobar.exe ends up as an orphan process and we need to then login to the server to terminate it using Task manager manually.

Does anyone have any solution so that the terminate signals from autosys propagate to the actual process ?

Thanks.


Solution

  • That is a known bug when dealing with Windows Autosys jobs. This is from the Autosys R11 Reference manual. I have never tried using this fix. Good Luck.

    Will the foobar.exe run without using the cmd.exe? I would try that and see if the KILLJOB event works properly.

    Windows does not support the concept of process groups. When you issue a KILLJOB event for a job that runs an executable (.exe), KILLJOB kills the process specified in the command definition. When you issue a KILLJOB event for a job that runs something other than an *.exe (for example, *.bat, *.cmd, or .com), KILLJOB terminates only the CMD.EXE process that CA Workload Automation AE used to launch the job. The Job Status is set according to the return code of the killed CMD.EXE process and can be one of the following: SUCCESS, FAILURE, or TERMINATED. Processes launched by user applications or batch (.bat) files are not killed. To work around this limitation, you can modify your programs to watch for a signal from a CA Workload Automation AE job running on a Windows machine, and you can implement this parameter for the SEND_SIGNAL event.*