Posting this here for dicussion before opening up an issue, because I haven’t thoroughly checked this yet.
The recent 1.18.3 syncthing release also contained 1.18.3 releases for stdiscosrv + strelaysrv in apt.s.n. A bit unexpected, but welcome .
However, both of my systemd services did not restart after the upgrade, even though they were enabled and running prior to the restart. Systemd logs show:
systemctl status strelaysrv.service ● strelaysrv.service - Syncthing Relay Server Loaded: loaded (/lib/systemd/system/strelaysrv.service; enabled; vendor preset: enabled) Active: inactive (dead) since Thu 2021-10-07 06:20:22 CEST; 19min ago Docs: man:strelaysrv(1) Main PID: 933 (code=killed, signal=HUP) CPU: 2min 9.075s Okt 02 00:55:35 <hostname> systemd: Started Syncthing Relay Server. Okt 02 00:55:40 <hostname> strelaysrv: 2021/10/02 00:55:40 main.go:140: strelaysrv v1.15.0 "Fermium Flea" (go1.16.3 linux-amd64) email@example.com 2021-04-06 06:03:> Okt 02 00:55:40 <hostname> strelaysrv: 2021/10/02 00:55:40 main.go:146: Connection limit 419430 Okt 02 00:55:40 <hostname> strelaysrv: 2021/10/02 00:55:40 main.go:239: URI: relay://0.0.0.0:22067/?id=<my-relay-id>&pin> Okt 07 06:20:22 <hostname> systemd: strelaysrv.service: Succeeded. Okt 07 06:20:22 <hostname> systemd: strelaysrv.service: Consumed 2min 9.075s CPU time.
I’m guessing that this may be related to the new way of handling systemd stuff. The exit code also indicates that the service was terminated due to HUP signal (generated by the upgrade script?!), but this didn’t trigger a restart of the service, only a non-restarting exit. I think the main syncthing binary restarts when getting that signal, so it works there, but not on the other binaries.
A simple exec of
systemctl start <service> got things back up to running state, but I expect services to do this themselves, at least if they were running/enabled previously.
The main syncthing service did restart as expected, just discosrv and relaysrv were affected.