-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
installer fails on macOS with error: unexpected EOF reading a line
#7242
Comments
relevant: #3605 |
maybe this has something to do with the installer being run without a TTY? |
#3605 speculates as much, though I think it meant underneath Nix or the test framework. There are still human-run cases like: |
We're seeing this quite frequently on macOS 12 in GitHub Actions CI when using the |
Hopefully this fixes "unexpected EOF" failures on macOS (NixOS#3137, NixOS#3605, NixOS#7242, NixOS#7702). The problem appears to be that under some circumstances, macOS discards the output written to the slave side of the pseudoterminal. Hence the parent never sees the "sandbox initialized" message from the child, even though it succeeded. The conditions are: * The child finishes very quickly. That's why this bug is likely to trigger in nix-env tests, since that uses a builtin builder. Adding a short sleep before the child exits makes the problem go away. * The parent has closed its duplicate of the slave file descriptor. This shouldn't matter, since the child has a duplicate as well, but it does. E.g. moving the close to the bottom of startBuilder() makes the problem go away. However, that's not a solution because it would make Nix hang if the child dies before sending the "sandbox initialized" message. * The system is under high load. E.g. "make installcheck -j16" makes the issue pretty reproducible, while it's very rare under "make installcheck -j1". As a fix/workaround, we now open the pseudoterminal slave in the child, rather than the parent. This removes the second condition (i.e. the parent no longer needs to close the slave fd) and I haven't been able to reproduce the "unexpected EOF" with this.
Hopefully this fixes "unexpected EOF" failures on macOS (NixOS#3137, NixOS#3605, NixOS#7242, NixOS#7702). The problem appears to be that under some circumstances, macOS discards the output written to the slave side of the pseudoterminal. Hence the parent never sees the "sandbox initialized" message from the child, even though it succeeded. The conditions are: * The child finishes very quickly. That's why this bug is likely to trigger in nix-env tests, since that uses a builtin builder. Adding a short sleep before the child exits makes the problem go away. * The parent has closed its duplicate of the slave file descriptor. This shouldn't matter, since the child has a duplicate as well, but it does. E.g. moving the close to the bottom of startBuilder() makes the problem go away. However, that's not a solution because it would make Nix hang if the child dies before sending the "sandbox initialized" message. * The system is under high load. E.g. "make installcheck -j16" makes the issue pretty reproducible, while it's very rare under "make installcheck -j1". As a fix/workaround, we now open the pseudoterminal slave in the child, rather than the parent. This removes the second condition (i.e. the parent no longer needs to close the slave fd) and I haven't been able to reproduce the "unexpected EOF" with this. (cherry picked from commit c536e00)
I suspect 8049 (or some other change) did fix this. |
Describe the bug
In my GitHub workflow I use
cachix/install-nix-action
to install Nix. It usually works fine, but this time it crashed and said I should post an issue here.The version of the action:
daddc62a2e67d1decb56e028c9fa68344b9b7c2a
The Nix installer is invoked with:
--no-channel-add --darwin-use-unencrypted-nix-store-volume --nix-extra-conf-file /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmp.bZo25Clt/nix.conf --daemon --daemon-user-count 6
Is this problem specific to the GitHub action?
Log output
The text was updated successfully, but these errors were encountered: