Feat/startup connectivity check - #2037
Open
leochien0102 wants to merge 3 commits into
Open
Conversation
…boot At boot the service could start before the WAN link was usable. Node domains then failed to resolve via get_host_ip(), leaving the service "running" while no traffic could actually pass. Add a configurable startup connectivity check that gates the boot path only: - New "startup_check" UCI section, exposed under Advanced Settings - Two probe methods: DNS resolution (default) and ICMP ping. DNS matches what the service actually depends on at startup; ping cannot prove the resolver is ready - Configurable probe servers, resolve domain, retry count and interval - Runs from boot() only, gated by SSR_BOOT. Manual restarts, ssr-monitor restarts and component upgrades are never delayed: the node IP is already persisted in UCI by then, so the check would add nothing - On timeout the service starts anyway, so the check can never block startup indefinitely Also drop the 99-ssrplus-pppoe hotplug script. It slept a fixed 10s after a PPPoE ifup and restarted the service, which this check supersedes with an actual readiness probe that works on any WAN type, including single-arm setups with no WAN interface at all.
- Skip the boot wait when no main node is configured: a nil global_server means the service has nothing to resolve at boot - Use ping6 for IPv6 probe hosts, as busybox ping is IPv4-only - Clamp a zero retry interval to 1s so the probe loop never spins - Run the wait after check_run_environment so local environment problems surface before the network wait
busybox does not always ship the nslookup applet, so the startup connectivity check could silently fail on minimal builds. Prefer nslookup for a targeted query of the configured server and fall back to resolveip, which ships with netifd and is always present, resolving via the system resolver - the same path get_host_ip() uses at startup.
Collaborator
|
@leochien0102 这个PR你测试了吗？没问题吧？ |
Author
@zxlhhyccc 以下是单位设备这里的启动日志，3次等待，网络通了才启动SSRP 2026-08-12 16:00:39: gfw2ipset: Using iptables |
Collaborator
|
@leochien0102 明天我来测试一下，没问题我将合并。 |
Author
|
补一个x86+PPPoE场景的日志 |
Collaborator
|
@leochien0102 为什么不会检测？ |
Author
只在启动设备时会有这个等待，如果已经手动重启（修改配置或者更换节点之类的），不会触发等待，因为这种情况下，网络基本上是已经通了的。在设备启动时，会出现在网络还未连通时启动ssrp，此时ssrp状态显示运行中，但实际无法连接的情况。 |
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
2 participants
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.
目的
路由器开机时 WAN 链路可能尚未就绪，主节点域名通过 get_host_ip() 解析失败，
导致服务显示"运行中"但实际无法转发流量。本 PR 在开机路径增加可配置的联网检测，
等网络就绪后再启动服务。
特性
startup_checkUCI 段，在"高级设置"中可配置现改为对任意 WAN 类型都有效的真实就绪探测）
提交