#+TITLE: Syncthing Service Conflict Issue
#+DATE: 2026-01-21

* Problem

archsetup enables the system service:
#+begin_src bash
systemctl enable "syncthing@$username.service"
#+end_src

However, the user service can also get enabled (either by default or manually):
#+begin_src bash
systemctl --user enable syncthing.service
#+end_src

When BOTH services are enabled, they fight over the same lock file:
=~/.local/state/syncthing/syncthing.lock=

This causes one or both to fail with:
: Failed to acquire lock: is another Syncthing instance already running?

* Symptoms

- Syncthing fails to start or keeps crashing
- Lock file errors in journalctl
- Two syncthing processes running with different parent services
- Config changes don't persist (one service overwrites the other)

* Recommendation

Standardize on ONE service type. Options:

** Option A: User Service (recommended for desktops)

Runs when user logs in. Cleaner for desktop use.

Change archsetup from:
#+begin_src bash
systemctl enable "syncthing@$username.service"
#+end_src

To:
#+begin_src bash
# Enable user service (requires user session)
sudo -u "$username" systemctl --user enable syncthing.service
#+end_src

Note: User services require lingering or an active session:
#+begin_src bash
loginctl enable-linger "$username"
#+end_src

** Option B: System Service (recommended for headless/servers)

Runs at boot without user login. Better for servers.

Keep current archsetup config, but ensure user service is disabled:
#+begin_src bash
systemctl enable "syncthing@$username.service"
# Explicitly disable user service to prevent conflicts
sudo -u "$username" systemctl --user disable syncthing.service 2>/dev/null || true
#+end_src

* Resolution on ratio (2026-01-21)

Disabled system service, kept user service:
#+begin_src bash
sudo systemctl stop syncthing@cjennings.service
sudo systemctl disable syncthing@cjennings.service
systemctl --user enable syncthing.service
systemctl --user start syncthing.service
#+end_src