-
Notifications
You must be signed in to change notification settings - Fork 843
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failing to unpack GHC (sometimes) #4888
Comments
I'm also seeing this issue with Snapcraft which uses Multipass to build snap packages. It happens every time on a fresh build. https://forum.snapcraft.io/t/haskell-stack-snaps-help/11909 |
I'm really confused by this one, and would love to hear some thoughts from others. I can't see any reason why a SIGTERM would be sent to Stack, what process would be sending it, or what changes in the I am able to reproduce. |
@jamesdbrock provided a Dockerfile for reproing this in #4889, but it's not a reliable repro. I'm not familiar with Snapcraft @dmp1ce. Do you think you'd be able to put together a reliable Docker-based repro for easier testing? |
It isn't easy to get snapd installed in a docker container. snapd is needed to install snapcraft which in turn uses multipass to create a virtual machine for building snap images. Probably the easiest thing to do is run snapcraft on a spare computer running Ubuntu. Multipass might work in LXD but I'm not sure because multipass requires a KVM device. On Ubuntu the steps would be:
|
I tried to look into strace -e %signal stack setup --verbose
I'd like to capture a log of
but I cannot reproduce the error again. |
That Which ultimately led to this PR: #4902 I'd appreciate if those affected by this bug would be able to test this out and confirm that it fixes the problem for them. |
Wait for children to exit correctly (fixes #4888)
I'm not that familiar with the whole stack/stackage setup, so I'll have to ask. Are there builds with this change included available somewhere, e.g. using some specific tag on DockerHub or in an artefact store on the CI system you use? |
We have nothing automated (though I wish we did). I generated a Linux executable and uploaded it to S3, and started using it for typed-process. If you'd like to use it too, it's available at https://s3.amazonaws.com/www.snoyman.com/stack-1ed71cae36a64365ead72da1427e1685ccec8246.bz2 Relevant commit: fpco/typed-process@af31b7b#diff-354f30a63fb0907d4ad57269548329e3 |
Yes, that'll make it a little easier to try it out on CI services, since that's where I've observed the issue most frequently. |
Running Stack build provided by @snoyberg heals my woes, and my app builds without issues. |
I'm completely failing to reproduce without the fix for the last few days... don't ask me what's different on the various CI services I'm experimenting with. I can't even reproduce using @SkyWriter 's recipe above 😕 |
A new official release would be great – due to this issue, our CI builds fail more often than not nowadays. @snoyberg is there anything I can do (regarding maintenance tasks) to help make the new release happen faster? My email is in my Github profile. |
@neongreen The only holdup right now is that |
General info
The last couple of days I'm running into an issue where untaring of GHC fails:
Steps to reproduce
I don't have exact steps, but the code and CI builds are all open and available.
The code is available at: https://github.com/magthe/ci-test-hs/ (the branch Add Azure Pipelines)
Examples of CI builds at:
Building image locally (docker build -t foo:0 .) first failed, then I followed the suggestion and added --verbose, then it succeeded. Howerver, the CI builds keep failing sporadically.
Expected
I'm used to
stack setup
working like a charm.Actual
Well, see above.
Stack version
The version I'm using on VMs is the pre-built 2.1.1 downloaded from GitHub, e.g. https://github.com/magthe/ci-test-hs/blob/153ca80eaca23eae6444abdbf32e0e3b91240d76/.travis.yml#L15
The version used in container, including when building images, is the one that's found in
fpco/stack-build:lts-13
(I believe that's beenfpco/stack-build:lts-13.25
and thus stack 2.1.1)Method of installation
See above.
The text was updated successfully, but these errors were encountered: