Systemd Service and Monitoring

Running Syncthing interactively is fine for testing, but production deployments need it managed by systemd — auto-starting on boot, restarting on failure, and integrated with the system journal.

Learning Focus

Understand the difference between a user service (systemctl --user) and a system service (systemctl), and configure the one appropriate for your deployment with a proper restart policy.

Tool Snapshot

Mode	Command	Runs On	Config Path	Recommended For
User service	`systemctl --user`	User login (or lingering)	`~/.local/share/syncthing`	Personal machines, developer VMs
System service	`systemctl` (as root)	System boot, any user	`/home/syncthing/.local/share/syncthing`	Always-on VPS, NAS, headless servers

Option A — User Service (Recommended for Most Cases)

Syncthing ships with a user-mode systemd unit. Enable it for the current user:

enable-user-service.sh
# Enable and start immediately
systemctl --user enable syncthing.service
systemctl --user start syncthing.service

# Verify it is running
systemctl --user status syncthing.service

Expected output:

● syncthing.service - Syncthing - Open Source Continuous File Synchronization
   Loaded: loaded (/usr/lib/systemd/user/syncthing.service; enabled)
   Active: active (running) since Tue 2026-04-15 09:00:00 UTC; 5s ago

For user services to run without an active login session (required on headless servers), enable lingering:

# Allow user's services to run without an active login
sudo loginctl enable-linger $USER

# Verify
loginctl show-user $USER | grep Linger
# Linger=yes

Option B — System Service (Dedicated syncthing User)

This is the pattern for always-on servers where Syncthing runs as a dedicated, low-privilege user:

create-syncthing-system-user.sh
# Create a system user with no login shell and a home directory
sudo useradd -r -m -d /home/syncthing -s /bin/false syncthing

# Enable the system-level template unit (substitutes the username)
sudo systemctl enable syncthing@syncthing.service
sudo systemctl start syncthing@syncthing.service

# Verify
sudo systemctl status syncthing@syncthing.service

warning

Never use syncthing@root.service. Always create a dedicated syncthing system user to minimize the blast radius of any misconfiguration.

Writing a Custom Service Unit

If the packaged unit is missing or you need custom flags:

/etc/systemd/system/syncthing@.service
[Unit]
Description=Syncthing - Open Source Continuous File Synchronization for %I
Documentation=man:syncthing(1)
After=network.target
Wants=network.target

[Service]
User=%I
Environment=STNOUPGRADE=1
ExecStart=/usr/bin/syncthing serve --no-browser --no-restart --logflags=0
Restart=on-failure
RestartSec=5s
SuccessExitStatus=3 4
RestartForceExitStatus=3 4

# Hardening
PrivateTmp=true
ProtectSystem=strict
ReadWritePaths=/home/%I

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now syncthing@syncthing.service

Useful Service Management Commands

manage-syncthing-service.sh
# Status
systemctl --user status syncthing

# Restart (e.g., after config change)
systemctl --user restart syncthing

# Stop
systemctl --user stop syncthing

# View last 50 log lines
journalctl --user -u syncthing -n 50

# Follow logs in real time
journalctl --user -u syncthing -f

# Check if it survived a reboot
systemctl --user is-enabled syncthing
# enabled

Resource Limits (Optional)

On shared servers, cap Syncthing's CPU and memory:

override — resource limits
# Create override file
sudo systemctl edit syncthing@syncthing

# Add:
[Service]
CPUQuota=50%
MemoryMax=512M

Monitoring with systemd-analyze

service-timing.sh
# Boot time impact
systemd-analyze blame | grep syncthing

# Verify service restarts are working
systemctl --user kill -s SIGKILL syncthing
sleep 5
systemctl --user is-active syncthing
# active (restarted automatically)

Common Mistakes

Mistake	Effect	Fix
Starting as root without a dedicated user	Config in `/root`, security risk	`useradd -r syncthing` and use `syncthing@syncthing`
Forgetting `loginctl enable-linger`	User service stops at logout on servers	`sudo loginctl enable-linger $USER`
No `Restart=on-failure`	Syncthing stays dead after crash	Add `Restart=on-failure` to unit
Editing unit file instead of using override	Next package update overwrites changes	Use `systemctl edit syncthing@syncthing` for overrides

Option A — User Service (Recommended for Most Cases)​

Option B — System Service (Dedicated syncthing User)​

Writing a Custom Service Unit​

Useful Service Management Commands​

Resource Limits (Optional)​

Monitoring with systemd-analyze​

Common Mistakes​

What's Next​