So in a multi-user environment, I want Syncthing to start at login which is simple enough, but when I logout it still running under my user account. This causes a problem if someone else logs in under a different account because Syncthing presents my account to them.
If I manually close Syncthing and then log out, the next user can start Syncthing and it comes up empty and they can set their own syncs. This seems like it should work fine as long as two people don’t simultaneously log in, but how can I force Syncthing to close when a user logs off?
Any help would be great…
Thanks
BTW… I’m using Linux (Ubuntu) and I am syncing to a dataset on a NAS.
Interesting you should mention this theme — just this past week I noticed when I needed to use ctrl+alt+backspace in Linux to terminate my XFCE desktop environment due to overfilling my RAM, and neglecting to mount a swap partition, when I logged in again, Syncthing was still running in the background, even though I had launched it from the Nemo filesystem explorer, and not as superuser or anything like that.
You’ll probably need to investigate with your desktop environment / session manager how to handle this. Any GUI application connects to the X server / compositor and terminates because it loses that connection when the session ends on logout. However, Syncthing does not have anything to do with the graphical session so you need to make the window / session manager explicitly send a terminating signal to stop it on logout. How to do that is unfortunately very different between environments, so we might be able to help when you provide more details about that.
Another very convenient way is to just start Syncthing using systemd as a user service. By default, those get shutdown when the user logs out (closes their last session). If that’s available for you, look at the documentation for how to enable it. When installed from a suitable distribution package, this one command should suffice:
I think the preferred method would be for Syncthing to start automatically for every user on logon, and close on logout, so that systemd approach sounds promising. That command above would accomplish that on my distribution?
For me, it’s rare that two users log on at the same time, but might happen inadvertently if someone grabs a machine for a minute. I suppose once it’s successfully starting and closing for everyone, I could use the Syncthing GUI to configure different ports for each user.
Does that sound logical, or am I speaking in gibberish? LOL
Yes, unless systemd user lingering is enabled (in that case user services are not stopped after logoff, plus more). This usually not the default.
Note that you need to run this command for each user account you want to enable the service for, being logged in as that user. This may also require an actual session as that user, not a sudo/su pseudosession (it all depends on how systemctl connects to the systemd daemon, that’s all configurable of course).
So no dice. On Ubuntu Mate 22.04 the command work to enable Syncthing on logon.
systemctl --user enable --now syncthing.service
But when I log out, and log in as a different user, the previous Syncthing instance is still running. If I open the Syncthing address under the second user, it still shows the configuration for the initial user.
Very frustrating that the developers don’t seem to envision this as a multiuser application.
This is not a big deal, but I have a similar issue. Syncthing is started as a systemd user service on several devices. If I turn off/logout a connected laptop it appears to be still connected on other devices for several minutes. If I stop the service with systemctl --user stop syncthing.service, this is reflected immediately on other devices.
To test, I create a temporary user (uid1001). Rebooted. Then login to normal user (uid 1000) and logout. Login into new user (1001) and loginctl list-sessions shows user 1000 remains active. Two sessions listed 1000 and 1001.
Maybe your distribution configures systemd to enable lingering for all users by default, without mentioning them explicitly? That used to be the default behavior on traditional UNIX-like systems before systemd. So maybe your distro took a conservative approach there?