mirror of
https://github.com/EasyTier/EasyTier.git
synced 2026-10-08 10:56:13 -08:00
KKRainbow
7853ec8685
* fix(service): restart windows service indefinitely on failure The windows service was installed with only the AutoStart start type and no SCM failure actions configured. When the service failed during boot (e.g. network not yet ready, config load error), it reported SERVICE_STOPPED with a non-zero exit code and stayed stopped until started manually, which is reported as no auto-start after reboot in issue #1771. Configure failure actions on install and update when restart is not disabled: - three Restart actions (1s/5s/10s delay) with reset period Never; the SCM repeats the last action once the failure count exceeds the actions array, so restarts are retried indefinitely - set fFailureActionsOnNonCrashFailures so exits that report SERVICE_STOPPED with a non-zero exit code (the error path in win_service_event_loop) are also treated as failures; manual stops still exit with 0 and do not trigger a restart Also exit the service process with a non-zero code after reporting the error status. Without it the process stayed alive after reporting SERVICE_STOPPED and was only counted as failed after the SCM force-killed it, adding roughly 30s of dead time to every retry cycle. This matches the systemd path, which already generates Restart=always with StartLimitIntervalSec=0. The --disable-restart-on-failure option now also clears previously configured failure actions on windows. Verified on a real windows host: crash failures and reported-error failures both restart with the configured 1s/5s/10s cadence indefinitely, manual stops are not restarted, and --disable-restart-on-failure clears the actions. * feat(gui): add start-on-boot menu entry pointing to service mode Issue #1771 reports that users cannot find how to make EasyTier start on boot. Auto-start is provided by service mode, but the GUI offered no entry named after it, so the connection was hard to discover. Add a "Start on Boot" item to the settings menu. It opens the mode dialog with service mode preselected and shows an info message explaining that enabling service mode registers EasyTier as a system service that starts automatically at boot and keeps running in the background. When the dialog is opened with service mode preselected, the mode watcher in ModeSwitcher can run before the default config/log dirs have been resolved, leaving the fields empty and failing validation on save. Fill them from the resolved defaults after mount in that case. Add mode.autostart / mode.autostart_hint strings to the cn/en locales in frontend-lib. * fix(cli): stop collecting the --core-args flag into the service args InstallArgs.core_args was declared without an explicit `long`, so clap treated it as a trailing positional argument instead of a named option. Passing `service install --core-args --daemon ...` therefore collected the literal "--core-args" token into the value, and the installed service was registered with an invalid command line that failed on every start (observed on a real windows host: the binPath contained `easytier-core.exe --core-args --daemon ...`). Declare it as a real option (`long` + `num_args = 1..`) while keeping allow_hyphen_values and the trailing semantics: --core-args must be the last option of install and consumes everything after it. The bare-positional spelling (`service install --daemon`), the only correctly-working form before, now fails with a clear "unexpected argument" error; scripts written against it need to add the --core-args prefix. Add unit tests covering the flag, `=` and mixed forms.