DISTCC_SSH regression in v3.4 #434
Comments
|
distcc-ssh-client_1 | ssh: connect to host distcc-ssh-server port 22: Connection refused There is your problem
the only state distcc has is the lock files to avoid spamming a host, and marking failed hosts in the same way, which has a timeout. |
|
I see, but given that the CI builds started failing after v3.4, there is a change in behavior somewhere. Looking at successful build logs prior to v3.4, distcc used to fail with exit code 107 after failing to connect: Post-v3.4 distcc seems to keep on trying forever to distribute the job. Am I missing something obvious here? |
|
distcc-ssh-client_1 | OpenSSH_8.6p1, OpenSSL 1.1.1k 25 Mar 2021 I think your ssh is not configured correctly. |
|
The SSH issue is expected, since the distcc server container is started at the same time as the client container. Both of these containers are part of a smoke test where the client container is designed to try reconnecting a few times before failing. The only reason I brought this issue up is because I noticed a change in the behavior of distcc from v3.3.3 to v3.4: in v3.3.3 the client container would occasionally fail to connect and distcc would exit with 107 (but that was expected and it was designed to retry after a few seconds). Since v3.4, however, distcc does not exit, but keeps on trying forever. This is more of a heads-up rather than an issue, so feel free to close anytime if you find it irrelevant. I reported it because I didn't notice any relevant change in the changelog. |
If that is the case that is indeed a bug. SSH mode is quite inefficient, and I do not use it, and thus my motivation to work on this is little, however. If you want security I recommend you use WireGuard. I would love to be able to integrate WireGuard directly into distcc, but that is tricky because it would require a full TCP stack in distcc. |
Knock-knock! |
|
Please taking the name-calling somewhere else.
El lun., 26 jul. 2021 19:48, Alexey Sheplyakov ***@***.***>
escribió:
… The SSH issue is expected, since the distcc server container is started at
the same time as the client container.
Knock-knock!
Race condition!
Who's there?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#434 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAD4W4ROTEQ7ZAFHXBTALV3TZV7UXANCNFSM5A62VQCA>
.
|
|
Using Prior to this commit, Again, I don't know if this change in behavior was intended or not, I'm just bringing it up for consideration. |
With |
Since the commit a7dd5cf ("Try a new host after failing to connect instead of immediately falling back to localhost") distcc tries to choose a different host on connection/protocol errors. However when backoff is disabled (DISTCC_BACKOFF_PERIOD=0) distcc keeps retrying forever. To avoid the problem limit the number of retries (currently to 3) when backoff is disabled. Closes: distcc#434
- Repaired IP based access control (Closes: #42251) - Added systemd unit file (Closes: #40669) - Improved --allow-private, see distcc/distcc#451 - Removed clients.allow, commands.allow.sh: these have never ever worked - Avoid infinite loop when DISTCC_BACKOFF is disabled, see distcc/distcc#434 - Refuse to distribute files with the `.incbin` assembler directive, see distcc/distcc#461
Version 3.4 seems to be affected by a regression regarding
DISTCC_SSH, according to which the environment variable is only honored during the first connection attempt of distcc and ignored during any subsequent runs (assuming the distcc server is temporarily unavailable).I accidentally stumbled upon this issue when my CI started failing once Gentoo stabilized the relevant version.
Relevant CI log (truncated):
The text was updated successfully, but these errors were encountered: