Packer: Timeout Running an Elevated Task on Windows

[Siam1205]

Overview of the Issue

At our company, we use the packer null builder to setup a winrm connection used by the PowerShell provisioner that in turn start a long running process. This works fine up to the point when the execution reaches the 24 hours mark which results in the following error:

==> null: Provisioning step had errors: Running the cleanup provisioner, if present...
Build 'null' errored: Script exited with non-zero exit status: 267014.Allowed exit codes are: [0]

Reproduction Steps / Cause

After some analysis, we located the issue inside the <RepoRoot>\provisioner.elevated.go file. In fact, packer uses the Microsoft Task Scheduler in order to gain elevated rights. For this purpose, it creates a Task Scheduler description which is technically an XML document. The element <Task> contains a <Settings> child that in turn contains the <ExecutionTimeLimit> element. For the most recent packer versions, this element carries a hardcoded timeout of 24 hours.

Packer version

From 1.6.2.0

Operating system and Environment details

Windows 10 64 Bit

Problem analysis

According to the packer documentation, there is a timeout property common to all provisioners. In fact, we can verify that this property does work as expected for the PowerShell provisioner. Using this timeout renders the hardcoded Task Scheduler Timeout of 24 hours obsolete. Therefore, the Task Scheduler timeout could be set to PT0S meaning "indefinitely" according to the official Task Scheduler Documentation. In addition, it could be made parameterizable.

We set this timeout to PT0S, compiled a packer.exe ourselves and started a long running process which passed the 24 hours mark. Thus, we verified that this caused the problem.

Suggested solution

For future versions of packer, we would like to request the hardcoded Task Scheduler timeout to be parameterizable [or even be removed in case you can verify that it is in fact obsolete due to other timeout features that packer already supports].

[azr]

Hey @Siam1205 thanks for reporting, do you have a patch for us so that we can see exactly what you did ?

[Siam1205]

Hello @azr and thanks for the quick reply.

Of course. I simply changed the line

<ExecutionTimeLimit>PT24h</ExecutionTimeLimit>

of the file provisioner\elevated.go to

<ExecutionTimeLimit>PT0S</ExecutionTimeLimit>

and it works as desired.

However, due to this change we are bound to recompile packer ourselves and deviate from your officially released versions which is not ideal. Because of this and in order to inform you about the problem itself, I created this issue.

[azr]

Right I see it here, thanks: https://github.com/hashicorp/packer/blob/91c8afda8e6a645c153317a63f4b7540adbf8daa/provisioner/elevated.go#L73

[SwampDragons]

I'm fine with this change; I don't think there's a major compelling historical reason for the 24h limit. It's been 24h for as long as we've had a powershell provisioner. And I highly doubt _increasing_ the timeout would unexpectedly break a bunch of builds. Would you like to open a PR and get the credit for the commit, or would you prefer a maintainer do it for you?

[Siam1205]

Hello @SwampDragons,
thank you for your answer and your offer.

Would you like to open a PR and get the credit for the commit, or would you prefer a maintainer do it for you?

I would like to open a PR myself; not in order to get any credit but in order to have that done once on Github and to get used to the processes and workflows. I'm going to do it tomorrow.

[sylviamoss]

Closed by https://github.com/hashicorp/packer/pull/9994

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.