Bar toggle uses systemctl start/stop, so Syncthing never survives a reboot on pre-existing installs

[renews]

Summary

The bar's service toggle calls systemctl --user start/stop, never enable/disable. For anyone whose Syncthing was not installed through the plugin's own installer, syncthing.service is left disabled, so the service never comes back after a reboot — the toggle has to be flipped by hand at every login.

The two code paths

The unit is enabled in exactly one place, inside the installer:

https://github.com/ilyaZar/syncshell/blob/main/scripts/syncthing-install.sh#L100-L101

systemctl --user daemon-reload
systemctl --user enable --now "$service_name"

But that path is unreachable when Syncthing already exists. install_package() opens with ensure_initial_install(), which hard-fails unless state is missing:

ensure_initial_install() {
  local state=""
  state="$(installation_state)"
  [[ $state == missing ]] || fail \
    "Syncthing must be absent before installing it (state: $state)"
}

and detect_status() classifies any present binary as existing:

executable="$(command -v syncthing 2>/dev/null || true)"
...
if [[ -n $executable_path ]]; then
  state="existing"
  label="Existing installation found: working"

So for a pre-existing install, the only remaining control is the panel toggle:

https://github.com/ilyaZar/syncshell/blob/main/core/InstallationController.qml#L119

controlProcess.command = [
  "systemctl", "--user", start ? "start" : "stop", "syncthing.service"
]

Runtime-only. Nothing in the plugin ever enables the unit on this path.

Related: the plugin can't see enabled state at all

detect_status() reads LoadState and ActiveState and reports serviceAvailable / serviceRunning. UnitFileState is never queried anywhere in the repo. The panel therefore shows a green/running Syncthing that is silently set to not come back after reboot, with no indication anything is off.

Reproduce

# Arch, Syncthing installed outside the plugin
pacman -S syncthing            # or `omarchy pkg add syncthing`
systemctl --user is-enabled syncthing.service   # -> disabled

Add the plugin to the bar, click the toggle to start Syncthing:

systemctl --user is-active syncthing.service    # -> active
systemctl --user is-enabled syncthing.service   # -> disabled  (unchanged)

Reboot → Syncthing is not running.

Suggested fix

Make the toggle express persistent intent, matching what the installer already does:

controlProcess.command = [
  "systemctl", "--user", start ? "enable" : "disable", "--now", "syncthing.service"
]

enable --now / disable --now are idempotent and cover the runtime action too, so this is a drop-in for the current behaviour plus persistence.

Two things worth considering alongside it:

1. Surface the state. Add UnitFileState to detect_status() and emit e.g. serviceEnabled, so the panel can distinguish "running" from "running and will survive reboot". Even without a UI change this makes the condition diagnosable.
2. Don't couple the two irreversibly. Some people deliberately run Syncthing on demand. If mixing them is a concern, an alternative is to keep the toggle as start/stop and add a separate "Start at login" switch in the settings menu bound to enable/disable — more code, but it doesn't take the choice away.

Either way the current state is a trap: the plugin presents a service control that silently forgets.

Environment

• syncshell 0.1.6 (9454b41)
• Omarchy 4.0.1-1
• syncthing 2.1.3-1 (Arch)

[ilyaZar]

@renews thanks ! thats a well structured issue actually

in pre-existing installations that users already had an enabled state, there was no problem , so thats why I missed it; you re exactly right to flag this

The way I understand the problem is this, we have to manage the four states:

1. enabled + active
2. disabled + inactive
3. disabled + active
4. enabled + inactive

I want the config file to manage disabled/enabled, and the toggle in the top right corner to have active or inactive.

I am thinking about nudging the user to "enabled + active" vs. "disabled + inactive" as far as possible, to keep the plugin code lean and reduce bug surface. As the main operating states, the plugin would prefer to nudge the user to be in state 1 or 2 .

The toggle keeps switching between active/inactive. A default value is added to the config file saying enabled. The config can change to disabled. The user decides what he/she wants to drive, irrespective of active/inactive (which is handled by the toggle only). So if he/she decided to move to state 3 or 4., thats fine, just to allow for the flexibility.

If in some corner cases, there is state divergence , i.e. systemctl has enabled set (say the user sets this manually, not via the config file) vs. config saying disabled, or vice versa, a pop up is firing up once, prompting the user to align config file value and system state.

The toggle state takes precedence in the nudging behavior, so we assume:

• if the toggle says active the user is nudged toward enabled
• if the toggle says inactive the user is nudged toward disabled

The user, tho, has always a choice in that pop up. The pop up says in brackets (preferred) for the transition cases 1 and 2, bc. I find this the most logical. However, if the user still wants to have 3 and 4, thats fine too.

The pop up essentially informs the user about state divergence (config file vs. true system state regarding enabled/disabled), then either writes the config if the user wants to have system state enforced, or the system state is changed if the user wants to have the config file value enforced. This happens in the pop up.

If I am not doing an error here (so correct me if I am wrong !) after pop up and the user clicks/decides, the system state and config file value never diverge by construction bc. the user has to align them in the pop up. Still, you can have 4 states, but we prefer the most logical 1. and 2, hence the nudging described above via a (preferred) text after the two options in the pop up.

Of course, and this is optional, one could even go so far as adding a small clickable warning icon if the user, for whatever reason, operates in state 3 or 4, and if the warning icon is clicked, a button "change" which re-activates the pop up is built in; again with the same pop up dialog saying two options, but giving the (preferred) , thus nudging the user again in that direction to the preferred state. I imagine the pop up to say something like:

"User config (value of user config reported i.e. either of: enabled or disabled) diverges from system state (the opposite of the user config because we have divergence, so disabled or enabled respectively). Please fix to either:

1. option here whatever necessary to change to end up in cases 1. or 2., saying (preferred) in brackets thus nudging vs.
2. option the other if the user doesnt want that, and wants to be in 3. or 4.

"

let me know, if you have time and energy, if you have any thoughts here on this