summaryrefslogtreecommitdiff
path: root/assets/2026-01-21-syncthing-service-conflict.org
diff options
context:
space:
mode:
authorCraig Jennings <c@cjennings.net>2026-01-21 13:30:47 -0600
committerCraig Jennings <c@cjennings.net>2026-01-21 13:30:47 -0600
commitc16e5f9c3a92df53aa759df660f4af1199205f2a (patch)
tree1c77a66085427026180330694b965d2b91de3355 /assets/2026-01-21-syncthing-service-conflict.org
parent1c95bb393b31122aa35a3ae85351058accf74f32 (diff)
fix(archsetup): increase GRUB timeout and switch syncthing to user service
- GRUB_TIMEOUT 0→2 seconds for menu access - Syncthing: system service → user service with lingering to prevent lock conflicts - Update airplanemodetoggle for user service - Update validation to check lingering instead of system service
Diffstat (limited to 'assets/2026-01-21-syncthing-service-conflict.org')
-rw-r--r--assets/2026-01-21-syncthing-service-conflict.org72
1 files changed, 72 insertions, 0 deletions
diff --git a/assets/2026-01-21-syncthing-service-conflict.org b/assets/2026-01-21-syncthing-service-conflict.org
new file mode 100644
index 0000000..7f86b39
--- /dev/null
+++ b/assets/2026-01-21-syncthing-service-conflict.org
@@ -0,0 +1,72 @@
+#+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