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.
(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
Then…
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 : )
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.
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.
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.
