diff options
Diffstat (limited to 'assets')
| -rw-r--r-- | assets/2026-01-21-grub-timeout-request.txt | 4 | ||||
| -rw-r--r-- | assets/2026-01-21-syncthing-service-conflict.org | 72 |
2 files changed, 76 insertions, 0 deletions
diff --git a/assets/2026-01-21-grub-timeout-request.txt b/assets/2026-01-21-grub-timeout-request.txt new file mode 100644 index 0000000..fa03f62 --- /dev/null +++ b/assets/2026-01-21-grub-timeout-request.txt @@ -0,0 +1,4 @@ +* TODO Increase GRUB_TIMEOUT to 2 seconds +Currently setting GRUB_TIMEOUT=0 which doesn't give users time to access GRUB menu. +Change to GRUB_TIMEOUT=2 for a reasonable delay while keeping boot fast. + 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 |
