Go's http stack will eventually notice, but a TCP timeout can take up to 5 minutes, so the timeout in autopkgtest is nowhere near long enough to detect that.
It's also by far not a snapd-specific thing.
apt will experience the exact same issue and would also hold up boot if used through cloud-init.
The only reason why apt doesn't hold up boot here is because autopkgtest has specific logic to configure its proxy. That same logic is missing for snapd causing this issue.
So I don't think that messing with http/tcp timeouts in snapd is the right solution here.
Instead the main actionable items would be:
- Have the autopkgtest network reject packets rather than drop them (that would have avoided this issue)
- Have autopkgtest's proxy config logic also configure the proxy for snapd (either through unit override or through /etc/environment)
Either of those is sufficient to avoid this problem.
Go's http stack will eventually notice, but a TCP timeout can take up to 5 minutes, so the timeout in autopkgtest is nowhere near long enough to detect that.
It's also by far not a snapd-specific thing.
apt will experience the exact same issue and would also hold up boot if used through cloud-init.
The only reason why apt doesn't hold up boot here is because autopkgtest has specific logic to configure its proxy. That same logic is missing for snapd causing this issue.
So I don't think that messing with http/tcp timeouts in snapd is the right solution here.
Instead the main actionable items would be:
- Have the autopkgtest network reject packets rather than drop them (that would have avoided this issue)
- Have autopkgtest's proxy config logic also configure the proxy for snapd (either through unit override or through /etc/environment)
Either of those is sufficient to avoid this problem.