Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Long tasks result in logging frozen and provisioner stdout blocked #8426
When filing a bug, please include the following headings if possible. Any
Overview of the Issue
We have found that with both Virtualbox and QEMU builders, Packer will run an Ansible playbook but often freeze mid-way through if we log a lot of data. When frozen like this Packer will not respond with CTRL+C and must be sent a "kill -9" to abort the build.
Run the Ansible-Local provisioner and produce several thousand lines of log output.
Simplified Packer Buildfile
Any Ansible-local provisioner which produces a lot of output.
Operating system and Environment details
CentOS 7 VM on CentOS 7 host.
Log Fragments and crash.log files
No log output produced, as log freezes when this occurs even with debug logging enabled.
Hello @howels thanks for openning; I think this could have been fixed by #8356 I recently tagged a nightly release of packer; could you please tell us if the binaries you can find here work in your test case ?
I think we won't but otherwise we need more infos to debug this ! Like a simplified buildfile.
The new binary now gives me an error whilst doing the QEMU disk resize:
I have not changed QEMU versions between runs, this error is occuring only with this new binary. A bug exists here (#5969), not sure why this regression appears from 1.4.3->1.5.0?
Log with debug enabled:
More details included under the other bug, cannot test this at present due to the regression in #5969
Sorry. I have tried to test this but the instant I tried 1.5.0 I hit breaking bugs in the QEMU implementation which prevent me from testing. There have been serious QEMU builder regressions between 1.4.3 and the 1.5.0 nightly that you posted - if these can be resolved then I can re-test.
@azr, it seems to me that this issue should remain open until it can be confirmed that the nightly build you referenced does indeed fix this problem. As I understand it, @howels has not been able to confirm that the changes in that build do resolve his issue because of other bugs he has encountered in that build.
I'm going to lock this issue because it has been closed for 30 days
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.