So if there are no other methods being used to start Syncthing, there shouldn’t be a running Syncthing after the two “systemctl --user kill” commands above.
Temporarily stop issuing any more systemctl commands.
Reboot the computer.
Log in, but don’t issue any more systemctl commands yet.
Check for any running instances of Syncthing:
ps -ef | grep syncthing
If the command above returns anything but itself, you need to backtrack and find out how else Syncthing is being started at system boot time before continuing with any other steps.
(On a related note, generally speaking, it’s better to use “systemctl stop” instead of “systemctl kill” so that if ExecStop is defined in the systemd unit file, it’s used. Sending a kill signal directly to a process usually results in a graceful shutdown, but the end result might be different than via a normal shutdown.)
To me, it says that Syncthing is somehow running as user1 and not root. How exactly are you starting Syncthing while logged in as root?
How does Docker containers fit into the picture?
Are you trying to use Syncthing on a set of files that the containers are also accessing on the host?
I rebooted it and it seems to be returning more than just itself. I can also access the web GUI even though it is “disabled” in systemd. I am not familiar with the output of ps, so I will try to figure things out, but here is the output in case someone can help:
You seem to be looking at column four of the ps -ef output, which is the percentage of CPU used by the process, and taking this as a numeric uid for who “started” the process? I don’t know why you’re doing this but it doesn’t make any sense to me. The user ID of the process is in the leftmost column – user1.
Both Syncthing processes are owned by user1, with init (PID 1) starting Syncthing (PID 626), followed by the first Syncthing starting the second Syncthing (PID 751).
(For more verbose output that includes a process tree: ps -efH)
Since the first Syncthing was launched by init, it means it wasn’t systemd because init is the predecessor of all other processes, including systemd. So regardless of if systemctl --user stop syncthing is run as root and/or as user1, it won’t stop the Syncthing process listed in the ps output above.
Linux distros that use systemd have a pared down list of services started by init, so it’s very unusual to start Syncthing that way. Chances are that you previously added an init file to Debian 12’s /etc/init.d/ directory.