mirror of
https://github.com/Control-D-Inc/ctrld.git
synced 2026-09-04 13:36:35 +02:00
Cuong Manh Le
52b7aaab87
processCDFlags retries the resolver-config fetch indefinitely by design: a device that has no working network at boot must eventually come up. The loop had no cancellation, so a stop request arriving while the API is unreachable was ignored - the process kept retrying long after "Service stopped" was logged, doing work on behalf of a service the OS considers stopped. The Windows Firewall Mode incident showed this concretely: API retries continued 15 seconds after the stop completed, so stopping the service could not release what the process was still holding. Thread a context through processCDFlags and derive it from p.stopCh, in both the startup preflight and the config-reload path. The loop now returns as soon as the context is cancelled, checked both before a retry and after backoff returns (backoff can wake up on cancellation). A stop during preflight now exits the way a normal stop does, without Fatal, so the service manager does not treat it as a failed start and apply its restart policy to a service the operator just asked to stop. Also bind the two API requests in internal/controld to the caller's context. They were built with http.NewRequest, so an in-flight request ignored cancellation and waited out its own timeout instead. Covered by tests that assert what the incident needed: a stop request during preflight ends the retry/backoff loop and reports cancellation rather than continuing to retry after the service reports itself stopped, an already-cancelled context makes at most one attempt, and contextFromStopCh handles its three cases (cancelled by stopCh, released by cancel, usable with no stop channel). Removing either cancellation check makes these tests hang until the test timeout. The tests are also what exercise fetchResolverConfig, the seam this commit introduces. Sampling the stop state is the whole point of runAPIPreflight rather than doing this inline. A stop and a failure need opposite handling - one exits quietly, the other self-uninstalls a deleted device, surfaces the error to a mobile app, and reports a failed start - so the two must not be confused. Reading it from the context after cancelling would report stopped for every failure, since CancelFunc sets ctx.Err() regardless of whether anyone asked to stop; the stop channel is read directly instead, which also does not depend on the context watcher goroutine having been scheduled.