Commit fb370f8
committed
Add fail-fast timeout and diagnostics to cargo hakari disable
cargo hakari disable in the docker image build has hung intermittently for 28-70 minutes (e.g. run 26514779485 attempt 1 sat on it for 28m45s before being cancelled). Crucially, cargo printed no output for the entire 28 min, so we do not yet know which phase actually stalled - it could be package-cache lock, libcurl/TLS init, DNS, TCP setup, sparse index download, or a git fetch. Without that, any "fix" is speculation.
This change is intentionally limited to two things, both about making the next hang useful:
* timeout-minutes: 5 - the step now fails fast at 5 min instead of occupying the 70-min job slot. Healthy cold-cache runs finish in ~2 min (worst non-stall observed ~3 min), so 5 min keeps a comfortable margin.
* verbose cargo logging plus a pre-kill watchdog snapshot - CARGO_TERM_VERBOSE, CARGO_HTTP_DEBUG, and a targeted CARGO_LOG give Rust-level and libcurl-level visibility; at 4m30s a background snapshot dumps the live process tree (with wait-channel) and open TCP sockets so a silent hang still leaves evidence of what cargo was actually doing.
Once a future hang reveals the stall point, the real fix can be targeted. No release note: internal CI infrastructure only.1 parent 1e8e1f3 commit fb370f8
1 file changed
Lines changed: 24 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
98 | 98 | | |
99 | 99 | | |
100 | 100 | | |
| 101 | + | |
| 102 | + | |
| 103 | + | |
| 104 | + | |
101 | 105 | | |
102 | 106 | | |
103 | | - | |
| 107 | + | |
| 108 | + | |
| 109 | + | |
| 110 | + | |
| 111 | + | |
| 112 | + | |
| 113 | + | |
| 114 | + | |
| 115 | + | |
| 116 | + | |
| 117 | + | |
| 118 | + | |
| 119 | + | |
| 120 | + | |
| 121 | + | |
| 122 | + | |
| 123 | + | |
| 124 | + | |
| 125 | + | |
| 126 | + | |
104 | 127 | | |
105 | 128 | | |
106 | 129 | | |
| |||
0 commit comments