Killing or Failing Tasks

FlexNet Manager Suite 2023 R1 (On-Premises)

There is no direct way to kill tasks in the batch processing service. You may be able to interrupt and close executables called by the batch processor.

You can also 'fail' tasks; but misusing this feature in an attempt to interrupt and kill the task poses a considerable risk to system stability and data integrity. This is because failing the task only instructs the batch scheduler process to regard the task as dead, but does not stop the batch processor from running the task.

A task should only be failed when it is 'lost'. This term means that execution has finished in the batch processor, but the batch scheduler has not been notified of its completion. If the task imposes constraints (listed in Batch Processing Constraints), its coninued presence in the batch scheduler list may be blocking other tasks. In the very rare case of a suspected lost task, first validate that the batch processor is (still) configured properly to send messages to the batch scheduler; and then you can validate that a task is lost, and if necessary fail it, using these steps:

1. On your batch server, inspect the batch processor log files under %ProgramData%\Flexera Software\Compliance\Logging\BatchProcessScheduler.
2. If there are any error messages indicating that the batch processor cannot send messages to the batch scheduler, suspend this process, and first remedy the configuration of your batch scheduler and batch processor.
   Particularly for server identification issues, you may wish to re-run the PowerShell configuration scripts provided for installation and implementation, as these set up the correct relationship between the two services. You may alternatively need to repair permissions on the message queue; ensure MSMQ is running on all applicable servers; or take other action as required to remedy the particular problem. When these two services are again communicating properly, you may resume stepping through this process to clean up any task you suspect was lost during the period of messaging failure.
3. Execute:

   ShadowHost.exe BatchProcessTaskConsole.exe list-tasks  

   The output includes the message GUID, which can be used when searching the batch scheduler/processor logs. Depending on when the breakdown occurred in status messaging from the batch processor back to the batch scheduler, the suspect task may be shown as either Queued (if the batch processor hasn't yet picked up the task, or if the message that the batch processor started work did not get through) or Processing (if only the end-of-task success or failure message was lost). Any other value of the task status means that the task is not lost, and you should exit this process and review alternative explanations.
4. Re-examine the batch processor log file, now looking for evidence that the suspect task has indeed finished. Alternatively, in cases where the batch processor starts a child process, examine that process or its logs for evidence of completion.
   The underlying executables that are run in the child processes are listed in Batch Scheduler Command Line.
5. When the log files show the suspect task has definitely completed (successfully or otherwise, with mere completion being the requirement), and the list-tasks output still shows the same task as either Queued or Processing, copy the message ID from the output of the list-tasks command.
6. Substituting your copied message ID for the placeholder shown below, execute:

   ShadowHost.exe BatchProcessTaskConsole.exe fail-task  -m messageGUID

   The batch scheduler updates the status of the task to Error to mark the failure (you can verify this by re-running the list-tasks command shown earlier).

Any blocked tasks can now be queued by the batch scheduler, and then executed by the batch processor.