I run syncthing on a collection of xubuntu and Raspberry Pi Linux systems, mostly on my home LAN but also one virtual machine ‘outside’.
One of the Raspberry Pis reads temperatures (at 10 minute intervals) and stores them in a sqlite3 database, the database file is synchronised with other systems (both on my LAN and remote). The sqlite3 database doesn’t get updated on other systems until I do something that communicates with the Raspberry Pi, e.g. I connect to it using ssh or rsync copies some files.
Is this how one would expect it to work or is there something that should make syncthing update files more frequently? It’s not a major issue really I just wondered if it indicates that something isn’t working as it should.
Oh, I’m running syncthing v1.18.5 on all systems with pretty much default settings except allowing GUI connections across the LAN.
Probably Syncthing is set up as a user service which only runs when you are logged in. You can set it up as a system service instead so that it runs continuously in the background.
That is indeed what systemd user services do, at least by default. I’m not a systemd wizard, but this is all googleable. Syncthing itself couldn’t care less whether you’re logged in or not, as long as it’s running.
Well I 'stop’ped and 'enable’d syncthing on the system where it appeared to be only running when I was logged in and now it runs at system startup. I’ve logged out and logged back in and it’s still the original process running.
All I can think of is that it’s some subtle difference between starting a systemd service as root (even though it’s a user service) and starting it as the user (even though it still requires root privilege to do this).
Anyway it’s presumably sorted now and I’ll go and try and understand how systemd manages user services!
There’s a difference between running with —user and with @user. I think you are doing one on one system and the other on the other. I suggest reading up on systemd.
This is a system service, not a user service. The service is “enabled”, which means it’s starting at system boot.
This is also a system service, but it’s not enabled so not starting on boot. On this machine you have probably enabled the user service, which is not shown here.
Systemd system and user services refer to the context the service is in, rather than to the user used by the service.
Systemd system services are managed by the system-wide instance of systemd (PID 1). Usually permissions are configured to only allow the administrator access to that instance as it has full privileges over the system.
That does however not mean that systemd system services run as root - in fact they can run as any user with any level of permissions. Syncthings system service file (“template service unit”) is /lib/systemd/system/syncthing@.service. It can be configured to use any user via the syncthing@myuser syntax (which gets internally expanded into the template to use the parameter as the user).
Systemd user services are managed by the per-user instance of systemd. Those (usually) get created and destroyed as the user logs on or off. Hence user services (by default) cannot survive the logout of the user, and won’t run until the user has login. Because they’re bound to a local systemd instance, they naturally also can only run under the current user. Syncthings user service file is /usr/lib/systemd/user/syncthing.service. To invoke systemd in user mode, the usual syntax is to append --user to the command, e.g systemctl --user status syncthing.
Effectively, you rarely want to use a systemd user service for a daemon-like application as syncthing. You should instead just run it as a system service. As explained above, modifying system services usually requires administrative permissions, due to systemd’s authority over the system. This is however fairly tweakable and, with some configuration, you can give non-root users permission to modify certain services.
Probably a notice like “you probably don’t want this” with some of the above context at the start of the systemd user service autostart docs could help.
A big difference between user services and per-user system services is who can control them. For example starting and stopping the service without administrative privileges.
Some wrappers rely on that to provide an on / off switch for Syncthing. Such as this simple icon extension for GNOME Shell:
They specifically note it only works with a systemd user service. So discouraging that in our docs would not be helpful in all cases.
That should be, like, pinned, FAQed, printed, framed, and auto-referred to when autostart questions come up.