Stop Download.exe after a certain amount of time if subprocesses are blocked to unlock further deployment
It would be nice to have a feature in the agent implemented which stops the Download.exe and/or its subprocesses. At the moment the Download.exe process will never be stoped if a subprocess crashed or hangs because of a bad coded user script. This prevents the complete machine to get other deployments. The possibility to kill all subprocesses of Download.exe will make sure that this package will be not registered and the next package on priority list can be deployed.
How this could be perhaps realized:
The Download.exe is starting a script with a counter for lets say 60min (perhaps can be modified from GUI and ocsinventory.ini). After this 60min this script is checking if Download.exe is still running. If Download.exe is not running the sxript silently quits. If Download.exe is still running the script should kill all subprocesses of Download.exe or if this is to difficult to realize the script just should kill Download.exe and all subprocesses (taskkill /F /IM Download.exe /T).
If this feature can not be implemented in the agent or you do not like to then another possibility could be to write a .vbs script which can be deployed on any agents plugins' folder.
In my environment I sometimes have a package deployment which is working on 99 hosts without problems but on one host it does not. If I have many other packages in the queue which should be deployed then this script blocks all other deployments until the user restarts its machine.
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Approved
- Assignee:
- Didier Liroulet
- Definition:
- Approved
- Series goal:
- Accepted for 2.x
- Implementation:
-
Implemented
- Milestone target:
- None
- Started by
- Didier Liroulet
- Completed by
- Didier Liroulet
Related branches
Related bugs
Sprints
Whiteboard
Another suggestion was posted here in the forum:
http://
Note that a buggy package could break deployment in a computer, stopping deployment indefinitely. This is a serious problem.
And then have the client return a new error type to the server if the timeout is reached and the package is canceled, so it is easy to keep track of which clients and packages are having problems. - Josh Stompro
I've opened a Bug: https:/
=======
Hello,
This is implemented in agent release 2.0.4.4.
When download process launches a command for a package, it wait for command ending for max 120 minutes (this setting will be configurable from server in 2.0.6 or higher).
If package command crashes or become in timeout more than 5 times, package is considered in error using code ERR_EXECUTE_PACK.
Regards
Didier Liroulet
=======
Hello,
Does this change have an impact on the choice of timeouts for the Warn User feature of package building? If I set my Warn User timeout to 120 minutes, will that mean that the install will never happen because the agent installer will time out at the same time that the warn user dialog times out? If that is the case then this timeout should be documented on the New Package Building page. Perhaps it should say "seconds (max ($agenttimeout-
