Dear Maintainer,

Whenever I reboot my Debian system and login, syncthing fails to start
automatically. I usually don't notice until a few days later when I notice
things haven't been syncing, then I have to remember that I rebooted recently
and start it manually. Once started manually, it stays running until the next
reboot.

After failing to start automatically, `systemctl --user status syncthing` says:

syncthing.service: Scheduled restart job, restart counter is at 4.
syncthing.service: Start request repeated too quickly.
syncthing.service: Failed with result 'exit-code'.
Failed to start syncthing.service - Syncthing - Open Source Continuous File
Synchronization.

Looking a little more deeply with `journalctl --user -t syncthing --boot`, I
see messages like this:

WARNING: Starting API/GUI: listen tcp 127.0.0.1:8384: bind: address already in
use
WARNING: Starting API/GUI: listen tcp 127.0.0.1:8384: bind: address already in
use
WARNING: Starting API/GUI: listen tcp 127.0.0.1:8384: bind: address already in
use
WARNING: Starting API/GUI: listen tcp 127.0.0.1:8384: bind: address already in
use
WARNING: Starting API/GUI: listen tcp 127.0.0.1:8384: bind: address already in
use
WARNING: Failed starting API: listen tcp 127.0.0.1:8384: bind: address already
in use

Evidently syncthing can't bind te ports it needs to listen on, it tries several
times and fails, then systemd restarts it, and after a few restarts systemd
also marks the service as failed.

This was very puzzling to me because I'd just rebooted - what else could
possibly be listening on the syncthing ports? Today I decided to go one step
further, and check the system-wide journal too:

INFO: syncthing v1.29.5 "Gold Grasshopper" (go1.24.9 linux-amd64) debian@debian
2025-11-29 20:48:58 UTC
INFO: Generating ECDSA key and certificate for syncthing...
INFO: Default folder created and/or linked to new config
INFO: Default config saved. Edit /run/gdm3/home/gdm-
greeter/.local/state/syncthing/config.xml to taste (with Syncthing stopped) or
use the GUI

Apparently what's happening is that after the system boots, the greeter runs
under the `gdm3` user, which is apparently counted as a user session, so per-
user units like syncthing are started and bind the relevant ports. When I
login, that starts a *new* user session, and *another* copy of syncthing, which
fails to start because the ports are already bound. Eventually (I'm not sure
how) gdm3's copy of syncthing gives up, or is stopped, so days later when I
notice the problem I can start syncthing and it works perfectly.

It would be good if somehow syncthing could be configured to *not* start up for
system users like gdm3.

On Tue, 17 Feb 2026 16:08:08 +1100 Timothy Allen <thristian@gmail.com>  wrote:
 > Apparently what's happening is that after the system boots, the
greeter runs
 > under the `gdm3` user, which is apparently counted as a user session,
so per-
 > user units like syncthing are started and bind the relevant ports. When I
 > login, that starts a *new* user session, and *another* copy of
syncthing, which
 > fails to start because the ports are already bound. Eventually (I'm
not sure
 > how) gdm3's copy of syncthing gives up, or is stopped, so days later
when I
 > notice the problem I can start syncthing and it works perfectly.

I had tried to stop gdm3 from starting syncthing by trying to mask the
service, but gdm3 is a dynamically created user with a home directory on
a tmpfs, so the next time I rebooted the problem returned.

I've since discovered a symlink to syncthing.service in
/etc/systemd/user/default.target.wants/ which I guess makes it start for
*all* users by default. I've removed that symlink and that *seems* to
have addressed the issue. I don't recall adding that symlink myself, if
it was added by installing (or upgrading) the package it would be nice
if it did *not* do that.


Timothy.