search

WinRb / winrm-elevated

Runs PowerShell commands as elevated over Windows Remote Management (WinRM) via a scheduled task
Apache License 2.0
27 stars 17 forks source link

Add configurable timeouts for execution #24

Closed fwininger closed 4 years ago

fwininger commented 6 years ago

Hi @mwrock

I have an issue with the windows tasks scheduler, sometimes the task does not return in the "Ready" (state 3) after the execution. So the run command does not close. I have some sidekiq jobs that try to execute command for 5 days. I see that the powershell script have an infinite loop, I propose to implement a timeout that kill the loop after 1 day (the time define in the xml configuration of the task). The timeout is configurable for the end user.

Could you please consider this change ?

Thank you

mwrock commented 6 years ago

What is the state after execution? Is it still running(4)?

fwininger commented 6 years ago

Yes the state is still running when I go in RDP on the machine.

I know that is a strange bug but I can be occurred some time. It's very difficult to reproduice the bug because when we restart the windows server the problem is solved. It's a minor bug because we run scripts on lot of machines (many thousands) and I estimate that this bug occurs on 1 per 1000 computers.

But I think that it's very important for this gem to implement some timeout, we already have timeout on the winrm part with HTTP timeout, but in this case, the powershell process that monitor the tasks can be stucked and the HTTP timeout are not useful.

So let know if my solution looks interesting or I can work on a better solution to handle this kind of problem.

Thanks

tarraschk commented 6 years ago

👍 this issue is definitely encountered on a large Windows fleet, and can create a congestion in Sidekiq queues.

fwininger commented 6 years ago

Hello @mwrock,

Can you consider this PR?

Thanks !

mwrock commented 5 years ago

@fwininger did you want to implement the changes discussed here or should we close this?

fwininger commented 5 years ago

@mwrock : we currently use this diff in production and it's work almost well. I want to implement the changes discussed and an other change to configure the <ExecutionTimeLimit>PT24H</ExecutionTimeLimit> with the same timeout because we saw that in some case the tasks continue the execution after the timeout.

fwininger commented 4 years ago

@mwrock : I have implement our comment (with some delay :( )