Closed mefellows closed 9 years ago
Tracked the issue to d875f4b5f2f999cebdd55bf496f844580227465e. Looks like c.timeout
is never properly initialised. Updated and corresponding test case to follow.
Issue closed and update released.
(Put my comment in the wrong place)
There's a "connect" timeout that we get from the configuration. This is used from New
when we make our first request. Individual commands should not timeout, or should run a long time (such as when processing Windows updates).
Correct me if I'm wrong, but I if you "persist" the timeout from New
and use it in subsequent commands, what you are saying is the builder's start_timeout
should be applied to all commands.
You are correct, actually.
With some of my testing I had assumed it was actually the same thing applied at the command level - if the operation did not start within that time then it was considered a timeout.
As per line 1048 of http://www.dmtf.org/sites/default/files/standards/documents/DSP0226_1.0.0.pdf it actually is the operation time, BUT, measured from the time the request started to the time a response is generated (not until it is actually finished).
So, an operation could take 24 hours but if the timeout was set to 5m and a response was generated straight away (e.g. with a Write-Host "Starting long process"), it would never fail.
I suggest perhaps creating a separate configuration parameter operation_timeout
that is used for this purpose and defaults to the previous value of time.Minute * 120
.
I think in the ssh provisioner it would just run indefinitely. That's pretty much what I was going for with 120m. Can we get this effect without adding an operation_timeout
?
Fair enough. I guess until there is a need we should keep it simple. I'll revert the commit.
R6.1-4: If the wsman:OperationTimeout element is omitted, the service may interpret this omission as an instruction to block indefinitely until a response is available, or it may impose a default timeout.
Hate how that's so open to interpretation! 120m is such a magical value. But getting kicked out of a big Windows update is a bummer. Won't be surprised to see us revisit this.
sigh. Better to have some control I agree.
So, yeah, we need to revisit (see #44). Thoughts? Currently, we have a few options:
Having had a bit of a think, I'm currently in favour with the former, as parameterising this will be a bit of a pain in the butt and exposes some low level things which arguably should be hidden from the end user.
Until the day the ssh communicator imposes a timeout, the intent is to run forever and never timeout. I am not excited about adding a windows-/winrm-only configuration here. For my money, in this space, 24h pretty close to forever.
The
powershell
provisioner is not behaving in the latest release, all scripts finish with '0 bytes written for' notice. It appears to be unrelated to therestart-windows
provisioner as tested by not using it in a packer run.Example output: