Closed mdub closed 6 years ago
I see an attempt to fix this, in https://github.com/hashicorp/packer/commit/50fef50e4be908929daf5b917e95e48119678792.
Unfortunately, it doesn't appear to be working as planned. My hunch is that SIGTERM needs to be treated differently from SIGINT. I think that on Ctrl-C, a shell will send interrupt to all processes in the process group, so packer need not explicitly propagate SIGINT to child processes. But SIGTERM (via kill
) is typically only sent to the master process.
In my automation around packer this works for stopping packer with kill and behaving like Crtl-C.
kill -s 15 `pgrep -xo packer`
It would be nice if kill $packer_pid just worked as expected.
to be clear, you're expecting sigterm to be handled the same way as sigint? I looked through the code and whatever sigterm handling there used to be got removed in a refactor ages ago. Is there a reason sigint isn't sufficient?
It seems to me that sigterm should make sure all child processes have exited successfully, but not wait for resources to be cleaned up
from the original issue
[handling sigterm] allows for better integration with various tools expecting standard Unix semantics (for instance Jenkins, where cancelling a job will cause SIGTERM to be sent to the process).
which would make sense for cleaning up resources
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.
I'm using Packer to build an AMI.
I sent Packer a SIGTERM (e.g. using
kill $packer_pid
), expecting it to clean up, in the same way it does in response to Ctrl-C, i.e.Unfortunately, it not cleanup, but instead appeared re-try parts of the build process.
Details
Packer v1.0.4
Template
Command output
Final state
I can see that some
packer
process are still running