x/crypto/ssh/test: tests fail on macOS 14 #64959
Labels
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
OS-Darwin
Milestone
Comments
dmitshur
added
OS-Darwin
Builders
|
Change https://go.dev/cl/554115 mentions this issue: |
|
I can't reproduce it locally either. Not sure if related to #63937 |
|
Change https://go.dev/cl/554062 mentions this issue: |
|
This doesn't quite look like a symptom of #63937: there is nothing to suggest that the underlying |
|
The output for the pending change in https://go.dev/cl/554062 shows a more interesting failure mode: |
|
Some interesting differences vs. a
I suspect that the |
|
Hmm. The source of that very unique error message seems to be here: But it looks like the “default configuration” is just “not doing the custom Apple fork thing”, so maybe that's not the problem after all. Still, there are enough |
|
Change https://go.dev/cl/554077 mentions this issue: |
|
I tried @drakkan You mentioned having |
|
@dmitshur I have a 2017 iMac with macOS 13.6.3 (22G436) |
dmitshur
changed the title
gopherbot
pushed a commit
to golang/crypto
that referenced
this issue
Jan 8, 2024
For golang/go#64959. Change-Id: I2153166f4960058cdc2b82ae34ca250dcc6ba1c6 Cq-Include-Trybots: luci.golang.try:x_crypto-gotip-linux-amd64-longtest,x_crypto-gotip-windows-amd64-longtest Reviewed-on: https://go-review.googlesource.com/c/crypto/+/554062 Run-TryBot: Bryan Mills <bcmills@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
bcmills
changed the title
|
This is now mitigated by skipping the failing tests at head. Leaving open to investigate the root cause and hopefully remove the skips. |
gopherbot
pushed a commit
to golang/crypto
that referenced
this issue
Jan 8, 2024
… LUCI builder We don't yet understand why these tests fail, but the Apple sshd seems to have some non-trivial vendor patches, so it is plausibly a platform-specific bug in the test. Let's skip that failure mode on the whole platform until/unless someone has time to reproduce and investigate the failure. For golang/go#64959. Cq-Include-Trybots: luci.golang.try:x_crypto-gotip-darwin-amd64-longtest,x_crypto-gotip-linux-amd64-longtest,x_crypto-gotip-windows-amd64-longtest Change-Id: I9e43579469de3fe9329c093b5916bbed0edd3751 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/554077 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Nicola Murino <nicola.murino@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Bryan Mills <bcmills@google.com>
bcmills
removed
the
Soon
|
I wonder if this is related to the race reported in #64094. 🤔 |
The code for tcpip and streamlocal forwarding is not covered in test cases |
|
Hello, is there gomote access to a macOS 14 instance? This would make testing much easier. Thank you |
|
Hello, I was finally able to get access to macOS 14 (using QEMU/KVM on Linux). This error
does not seem relevant. The managed configuration directory resolves to The relevant error looks like this and occurs every time we open a session
It is generated here. In previous versions, this error was not fatal. In the latest version Apple added I guess the error happens because we start sshd in inetd mode like this if we start I'm not sure how to proceed, maybe we can start sshd in tcp mode on Darwin (or all platforms), this will complicate things. Please let me know what you think. Thank you |
|
It sounds like Apple has just completely broken Is it even feasible to start |
|
We generate a config file on the fly, we can set the port there. We should first find a free port from Go and then set it in the sshd configuration file, this could be problematic with parallel tests, if we want to proceed this way perhaps it is better to add a I guess Apple cares about |
It's problematic period. In a heavily loaded CI environment, we cannot assume that there aren't other processes running concurrently that may be opening previously-free ports. The usual solutions are to have the program allocate its own port (and log that for the consumer to connect to), or to avoid communicating over numeric ports entirely (instead using an |
drakkan
pushed a commit
to drakkan/crypto
that referenced
this issue
May 11, 2024
For golang/go#64959. Change-Id: I2153166f4960058cdc2b82ae34ca250dcc6ba1c6 Cq-Include-Trybots: luci.golang.try:x_crypto-gotip-linux-amd64-longtest,x_crypto-gotip-windows-amd64-longtest Reviewed-on: https://go-review.googlesource.com/c/crypto/+/554062 Run-TryBot: Bryan Mills <bcmills@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
drakkan
pushed a commit
to drakkan/crypto
that referenced
this issue
May 11, 2024
… LUCI builder We don't yet understand why these tests fail, but the Apple sshd seems to have some non-trivial vendor patches, so it is plausibly a platform-specific bug in the test. Let's skip that failure mode on the whole platform until/unless someone has time to reproduce and investigate the failure. For golang/go#64959. Cq-Include-Trybots: luci.golang.try:x_crypto-gotip-darwin-amd64-longtest,x_crypto-gotip-linux-amd64-longtest,x_crypto-gotip-windows-amd64-longtest Change-Id: I9e43579469de3fe9329c093b5916bbed0edd3751 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/554077 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Nicola Murino <nicola.murino@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Bryan Mills <bcmills@google.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See https://ci.chromium.org/ui/p/golang/builders/ci/x_crypto-gotip-darwin-amd64-longtest/b8759816251100556177/test-results for full details.
It doesn't seem to reproduce for me locally:
Nor on the old dashboard, though it's hard to be sure whether this test is running or being skipped there.
This failure is blocking the automated monthly tagging workflow, so adding Soon label. If this ends up taking a while to figure out and fix, we might want to temporarily skip the test since it's happening since the builder was added in LUCI, to unblock the rest of the tagging.
CC @drakkan, @golang/security, @prattmic.
The text was updated successfully, but these errors were encountered: