Packer: Feature Request - Provisioner timeouts

[wayneworkman]

As a packer user who relies heavily on bash and powershell scripts to build AMIs in Amazon Web Services, I would like to add a timeout to shell script provisioners via packer.

What I would like is to be able to use something like this:

"provisioners": [
      {
          "type": "shell",
          "execute_command": "chmod +x {{ .Path }}; sudo '{{ .Path }}' {{ user `aws_account_nickname` }}",
          "script": "/home/ec2-user/amis/scripts/provision.sh",
          "script_timeout": "60m"
      }
]
}

If the script fails to complete within the specified timeout, I want packer to consider the build a failure, cleanup the temporary keys, instances, security groups, temporary subnets, routes - the works - just as it would if it encountered an error.

This would prevent packer running infinitely because of a powershell script or bash script hanging.

I would like the default script_timeout to be one hour.

Also, thanks in advance to a highly responsive packer dev team! :-)

[SwampDragons]

This is a really interesting idea. A quick glance at the code tells me that this would probably have to be implemented inside the communicatior's StartWithUi function, which would have a pretty broad touch across the packer code. I still think it might be worth doing, since there seem to be plenty of odd edge-case situations where packer hangs indefinitely. What do you think @mwhooker?

[mwhooker]

thinking maybe we can solve this with https://github.com/hashicorp/packer/pull/4709 which is only partially done

The above PR is more about aborting the build if we don't hear back from the remote command. I want to make sure we understand this is different from aborting a build that is taking too long (but still progressing). I think your issue is more about detecting dead scripts, which agrees with the above approach.

It may be that a 5 minute deadline is acceptable. I don't know that cases where a script is making progress but not outputting anything is common. I don't necessarily think this belongs in the provisioner config, since this will be globally applicable, but the UI is something I'm flexible on. It's my hope that the setting of 5 minutes works for 99% of cases, and if so I think we can configure it with an env var.

[wayneworkman]

4709 is for ssh. I opened 4819 because of a powershell problem.
On Sep 28, 2017 6:46 PM, "Matthew Hooker" [e-mail] wrote:

thinking maybe we can solve this with #4709
https://github.com/hashicorp/packer/pull/4709 which is only partially
done

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/packer/issues/4819#issuecomment-332993290,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMsq7_LQeMStPU9Uo7pL0inJChX9Ycy4ks5snC_RgaJpZM4NErKZ
.

[mwhooker]

That wasn't obvious. Perhaps the same solution in #4709 can be adapted to winrm

[mwhooker]

Looks like we can add a Timeout to the winrm endpoint https://github.com/masterzen/winrm/blob/b09cde26d67bcb0c7cbf02b16bb26b7f8fb0171e/endpoint.go#L27-L29

[jurajseffer]

I could use this feature right now as I have a build that appears to be stuck and we only print the output from the provisioner at the end of it so as it is now it will run forever.

[justinmetz]

Would anyone happen to know if this feature will eventually be implemented or not? It's a fantastic idea that would really save a lot of heartache due to real world scenarios..

[SwampDragons]

I definitely agree it's a good idea -- the issue is still open because I'd like to see it implemented. That said, it isn't currently top of my list. I can probably slate it for a few releases from now, but if you want to see it sooner you may need to make your own PR. :-/

[justinmetz]

OK thanks, at least we know it's still on the list. : ) If I knew Go well enough to contribute I surely would. Thank you for all your great efforts!!

[SwampDragons]

This was closed by https://github.com/hashicorp/packer/pull/7466 :D

[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.