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 |
edolstra
added a commit
to edolstra/nix
that referenced
this issue
Mar 15, 2023
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.
7 tasks
Ericson2314
pushed a commit
to Ericson2314/nix
that referenced
this issue
Oct 31, 2023
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)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
In my GitHub workflow I use
cachix/install-nix-actionto install Nix. It usually works fine, but this time it crashed and said I should post an issue here.The version of the action:
daddc62a2e67d1decb56e028c9fa68344b9b7c2aThe 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 6Is this problem specific to the GitHub action?
Log output
The text was updated successfully, but these errors were encountered: