Syncthing idle/dormant unless terminal session active

Syncthing in LXC container won’t stay active unless a SSH session remains active into the container.

As long as I remain ssh’d in with putty, Syncthing devices show the instance as connected and ‘Up to date’. If I terminate the ssh session, quickly the statuses change to “Disconnected”. Re-establish the ssh connection and all return to connected and ‘Up to date’ status again.

50/50 it’s a Proxmox thing, so I posted there first. Haven’t had any bites with ideas so I’ve posted it here as well.

Container is privileged and running Ubuntu 21.04 (Linux 5.4.114-1-pve #1 SMP PVE x86_64 GNU/Linux with Syncthing 1.17 running as a normal user (container is privileged as I am still learning to share data stored on separated bare metal TrueNAS using this instance).

Anyone else experience similar behaviour? Suggestions appreciated.

You haven’t explained how you are launching syncthing, but all child processes launched during the SSH session are usually terminated as the session ends, so if you expect it to keep running after you logged off, this is not going to happen, as expected.

Here are the steps I followed to set up the LXC and get Syncthing going:

1. Create LXC from the 20.04 LTS Server template

(updated to 21.04 from within running LXC since).

2. Install Syncthing following these steps:

apt install curl apt-transport-https gnupg
curl -s | apt-key add -
echo "deb syncthing release" > /etc/apt/sources.list.d/syncthing.list
apt-get update
apt-get install syncthing

3. Create Service File

nano /etc/systemd/system/syncthing@.service
Description=Syncthing - Open Source Continuous File Synchronization for %I
ExecStart=/usr/bin/syncthing -no-browser -gui-address="X.X.X.X:8384" -no-restart -logflags=0
SuccessExitStatus=3 4
RestartForceExitStatus=3 4


4. Reload daemons

systemctl daemon-reload

5. Start Syncthing when booted (non-root)

systemctl --user enable syncthing.service
systemctl --user start syncthing.service

(I had this all cut and paste ready for my next install)

6. Check Status

systemctl --user status syncthing.service

* syncthing.service - Syncthing - Open Source Continuous File Synchronization
     Loaded: loaded (/usr/lib/systemd/user/syncthing.service; enabled; vendor preset: enabled)
     Active: active (running) since ...
       Docs: man:syncthing(1)
   Main PID: 1435 (syncthing)
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/syncthing.service
             |-1435 /usr/bin/syncthing serve --no-browser --no-restart --logflags=0 --gui-address=10....10:8384
             `-1442 /usr/bin/syncthing serve --no-browser --no-restart --logflags=0 --gui-address=10....10:8384

Jul 03 22:31:56 sync-nas syncthing[1435]: [12345] INFO: Detected 0 NAT services
Jul 03 22:32:09 sync-nas syncthing[1435]: [12345] INFO: Failed to exchange Hello messages with garbledygook001>
Jul 03 22:32:09 sync-nas syncthing[1435]: [12345] INFO: Established secure connection to garbledygook001HLAM a>
Jul 03 22:32:09 sync-nas syncthing[1435]: [12345] INFO: Device garbledygook001HLAM client is "syncthing v1.17.>
Jul 03 22:32:09 sync-nas syncthing[1435]: [12345] INFO: Connection to garbledygook001HLAM at 10....10:22000>
Jul 03 22:32:15 sync-nas syncthing[1435]: [12345] INFO: Established secure connection to garbledygook001HLAM a>
Jul 03 22:32:15 sync-nas syncthing[1435]: [12345] INFO: Device garbledygook001HLAM client is "syncthing v1.17.>
Jul 03 22:32:15 sync-nas syncthing[1435]: [12345] INFO: Ignoring folder "Manuals" (dirname1) from device grapplegrommet999>
Jul 03 22:32:32 sync-nas syncthing[1435]: [12345] INFO: Completed initial scan of sendreceive folder "Data" (dirname2)
Jul 03 22:32:47 sync-nas syncthing[1435]: [12345] INFO: Joined relay relay://24.....9:59771


When I’m connected, devices show this instance ‘Up to date’ in their status lists. Once I disconnect, within seconds, those statuses change to ‘Disconnected’. When I again ssh into the LXC , seconds later all return to ‘Up to date’.

And by ssh’ing in to LXC, I mean name and password and that’s it. Just leave cursor sitting at the prompt, until you type ‘exit’ when all will again disconnect. I’m checking now to see if the Proxmox web based console performs in the same manner.

For some reason, either Syncthing or the LXC takes offense to being left alone in the dark, and rebels by sleeping til again accompanied : )

Explaining odd behaviour when all is new just adds to the challenge. Any and all tips from fellow fiddler’s welcome : )

It’s probably because you have an encrypted home directory, so it disappears when you log off.

Thanks for suggestion. I’ll check for any stray encryption settings, but thought them all off as I’m learning and not yet live, so haven’t intentionally enabled any encryption.

I’m thinking its something container related. This is my second go at a Syncthing server for the NAS. Round 1 used a full blown X windows VM setup and worked well except it was top CPU/memory using VM so I’m trying to improve its efficiency. X not needed so maybe next try I’ll create a VM with server and no X and see how it performs instead of a container.

I guess you could log in as a different user and see what happens to the process.

Systemd “user” services only run when the user is logged in, don’t they?


You installed the systemd user unit, which will only run during active user sessions. Instead, use the system service template:

sudo systemctl --enable syncthing@yourusername.service
sudo systemctl --start syncthing@yourusername.service

Don’t forget to disable the user service again. And in general you don’t need to create the systemd unit files manually, they are installed with the Debian package.


:bulb::bulb::bulb:… and the heavens’ parted… THANK YOU!

Sysadmin lessons that should’ve been previously learned are the bane of my home lab two footed jumps : ) It was doing exactly as told. But like everyone, it’s supposed to do what I mean, not what I say : )

I disabled the user init calls and used the system service template as suggested. Now all is well, syncthing remains active regardless of user login. I’ll mark this solved if I figure that out.

Follow up (again, sysadmin 101…): The sudo systemctl command executes as root, but the associated syncthing@yourusername.service runs under “yourusername”, correct? The goal being to not run syncthing as root.

And again, the receding flat spot on my forehead thanks you profusely : )

Yes, this is what the parameter is for. Syncthing would also spit out big red warnings if it were running as root.

Systemd system services can run under any user, altough the default is root. Syncthings inbuild service file therefore allows specifying the user as parameter to the service name (this also allows enabling multiple services, each running syncthing under a different user).

The fact that you run systemctl as root is because systemctl sends data to the systemd daemon, which requires a privileged user for many actions - the systemd daemon is really powerful and should therefore only respond to privileged commands by authorized users, e.g root. The daemon itself can spawn processes with arbritary privileges and users - all configurable via the service file.

By the way, the commands above can be simplified to (assuming systemd version 220+):

sudo systemctl enable --now syncthing@yourusername

--now is a nice shortcut to combine creating the symlink and actually starting the service. Also works with the opposite operation disable.

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