Repository navigation
Conversation
stop_core_service turns the system proxy off when the user stops the core, but nothing does when the core dies on its own: a crash, an OOM kill, a terminal that closes and takes the core's process group with it. The machine is then left pointing every proxy-aware app at a closed loopback port, which reads as "the whole machine has no internet" and is not something the user can guess. Terc now drops its own entry when it starts and finds the core unavailable, so opening terc once restores connectivity. Only an entry that is loopback on one of this config's ports is touched; a corporate proxy is left alone. The ports lookup the stop path already did becomes release_stale_sysproxy, which both call sites share.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
stop_core_serviceturns the system proxy off when the user stops the core, butnothing does when the core dies on its own: a crash, an OOM kill, or a terminal
closing and taking the core with it. The machine is left with its proxy setting
pointing at a closed loopback port, so every proxy-aware app fails - it reads as
"the whole machine lost its internet", and there is nothing in terc that shows
why.
The TUI now drops terc's own entry when it starts and finds the core
unavailable, so opening terc once restores connectivity. The ports lookup the
stop path already did becomes
release_stale_sysproxy, shared by both callsites.
Safety
Only an entry that is loopback on one of this config's ports is touched
(
proxy_is_oursand the macOS and GNOME variants); a corporate proxy, or aloopback proxy on another port, is left alone. Nothing is ever switched on, and
the check runs only when the core is already down.
Testing
cargo fmt --check,cargo clippy --all-targets --locked -- -D warnings,cargo test --all-targets --locked(340 passed). By hand on the Windows portthis was reported from: stopping the core with the system proxy on, then
launching, leaves the machine on direct internet instead of a dead proxy.