Delay updating files on LAN, until something else connects

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.


Yes, it’s a user service on all systems. Do I need to be logged in at both ends for files to be synchronised?

Anyway the syncthing process surely doesn’t stop running when I log out does it?

I’ll try logging in as another user to check.

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.

Hmm, something is amiss. On one of my Raspberry Pi systems syncthing is started (as a user service) when the system starts up:-

chris@dns$ systemctl status syncthing@chris.service
● syncthing@chris.service - Syncthing - Open Source Continuous File Synchronization for chris
   Loaded: loaded (/lib/systemd/system/syncthing@.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2021-12-20 08:22:28 GMT; 3 days ago
     Docs: man:syncthing(1)
 Main PID: 443 (syncthing)
    Tasks: 20 (limit: 2059)
   CGroup: /system.slice/system-syncthing.slice/syncthing@chris.service
           ├─443 /usr/bin/syncthing serve --no-browser --no-restart --logflags=0
           └─471 /usr/bin/syncthing serve --no-browser --no-restart --logflags=0

But on the other system it’s being run by systemd but it (systemd) denies any knowledge:-

chris@backup$ systemctl status syncthing@chris.service
● syncthing@chris.service - Syncthing - Open Source Continuous File Synchronization for chris
     Loaded: loaded (/lib/systemd/system/syncthing@.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:syncthing(1)
chris@backup$ ps -ef | grep syncthing
chris    10361 10342  0 13:48 ?        00:00:00 /usr/bin/syncthing serve --no-browser --no-restart --logflags=0
chris    10375 10361 13 13:48 ?        00:00:03 /usr/bin/syncthing serve --no-browser --no-restart --logflags=0
chris    10430 10380  0 13:48 pts/0    00:00:00 grep --color=auto syncthing

chris@backup$ ps -ef | grep 10342
chris    10342     1  0 13:48 ?        00:00:00 /lib/systemd/systemd --user
chris    10343 10342  0 13:48 ?        00:00:00 (sd-pam)
chris    10361 10342  0 13:48 ?        00:00:00 /usr/bin/syncthing serve --no-browser --no-restart --logflags=0
chris    10550 10380  0 13:50 pts/0    00:00:00 grep --color=auto 10342

As far as I’m aware both these systems are running the same OS etc. but there’s obviously something different.

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! :slight_smile:


1 Like

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.


:+1: That should be, like, pinned, FAQed, printed, framed, and auto-referred to when autostart questions come up.


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.

1 Like

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.

You can also change the behaviour for user services to start and stop with the system, not user session: arch linux - Make user systemd service persistent - Unix & Linux Stack Exchange

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.