I’m having trouble getting Syncthing to autostart as a system-wide service on Linux Mint 19/Ubuntu 18.04, without requiring a user to log in. I installed Syncthing after adding the repos to sources.list rather than the packages supplied by Ubuntu. I followed these instructions from the autostart page:
Create the user who should run the service, or choose an existing one.
Copy the Syncthing/etc/linux-systemd/system/syncthing@.service file into the load path of the system instance.
Enable and start the service. Replace “myuser” with the actual Syncthing user after the @:
systemctl enable syncthing@myuser.service
systemctl start syncthing@myuser.service
I’ve tried using “root” and “mozzie” (my system username) as “myuser” in the systemdctl commands above and also adjusting the ‘User’ entry in the systemd service script but nothing will start Syncthing on boot, but both usernames initiate Syncthing AFTER logging in. I presume “actual Syncthing user” is the system username rather than a username provided by the Syncthing application? As I’m trying to get Syncthing to run on two normally headless machines I need to get it to boot without a user logging in, system-wide.
The instructions aren’t too clear leaving users wondering why a user is needed on a system-wide setup, whether “myuser” is a system user or a Syncthing specific user and where to find the proper syncthing@.service file (mine was in a lib directory). Most of the other threads in the forums are regarding user autostart rather than system.
Because everything on a Unix like system is run as a user and the default for a service would be root (the admin account for the machine). This is not good practice so we suggest you run it as a user without special permissions.
I’ve got the user “mozzie” as the main user on my system and have tried it with the systemctl commands to enable it. It starts fine, when I log in as mozzie, but using the provided instructions it doesn’t start when the systems boots, only after login. I’ve tried on both a Linux Mint test server and an Ubuntu 18.04 VPS using the ‘system’ rather than ‘user’ autostart instructions.
I think that’s how user services work in systemd. You probably want a system service, or whatever it’s called, where there is no “@” in the name and the user is specified in the unit file. When I’ve needed this on systemd systems I’ve just copied some other thing that is similar, like the sshd unit, and modified it accordingly. wrong apparently
The @ services are not user services. It’s just a convenience notation to have a single system service file named syncthing@.service that can be run as differing users. You could also define the user within the service file and make a syncthing.service system service. User services always need the --user parameter. Running systemctl enable syncthing@mozzie.service does start syncthing for user mozzie on boot - if it doesn’t something is wrong. Check systemctl status syncthing@mozzie.service.
This is the ‘something is wrong’ I think
The service doesn’t start on boot. I’ve got two laptops in front of me at the moment, if I boot and log in to the desktop on one, and just boot to the login screen on the other, checking the Syncthing web UI indicates the one that just boots to login is disconnected and never appears. As soon as I log in on that machine, Syncthing connects and sync starts.
I’ve changed the UI to be accessible on 0.0.0.0:8384 on both laptops now to see if I can view the UI over the LAN. If I don’t log in on the target machine I get “Server not found”. As soon as I log in I get the Syncthing UI available over the LAN.
I’ve removed all Syncthing systemd services, reimplemented them using root, mozzie and testuser users and no matter which I use Syncthing is accessible after log in via any user, but not before.
Checking journald, which is a performance in itself, it seems to confirm Syncthing is only starting up after log in. Given how pathetic systemd is at logging and how difficult it is to find the right journald for the right user I’m wondering if this is more a systemd issue than Syncthing. There’s no errors/warnings from journald but I had a similar problem with getting tinc-vpn running and after several OS reinstalls/ and days crawling forums I gave up eventually. Most other services I’ve set up haven’t been a problem, even with starting VM’s and containers at boot with custom services.
Not on the two laptops or the VPS that I tried things on first. On the desktop, yes, but I was using root user on that to get Syncthing going. When I tried ‘mozzie’ on the desktop I put the mozzie username in the systemd service script.
Okay, it’s a hack and the problem is still outstanding but my temporary solution to this has been to install Syncthing on Devuan, running inside a VM with sensible sysinit scripts instead. I’ll try getting it into a container to cut the overhead (and maybe a container is a more sensible permanent solution too?) but currently starting with systemd for system-wide rather than user is a no go for me.
I’ve used the supplied service scripts and the instructions on the autostart info page, bog-standard installs of Mint 19 and Ubuntu 18.04 and can’t get it to work.
Syncthing is a cracking piece of software and I really appreciate the project. The documentation for autostart does need slightly clearer explanation (as another thread has highlighted) but until I get this working with systemd I can’t claim the explanation is incorrect in any way. Thank you for your help and a great piece of software guys. I’ll update as soon as I’ve made some headway but I’ve a lot of work to catch up on
FWIW I still find myself installing runit on systemd systems, and running my stuff under runit instead. Runit itself is started by systemd in Debian, but I can pretend I don’t know this and not care.
Thank you Jakob, Runit does the job great. Pulled Syncthing out of the VM and now starting at boot as it’s own dedicated ‘syncthing’ user. Systemd is an absolute horror, though apart from running Ubuntu 14.04 there’s no sysinit/upstart/openrc options left these days on any VPS/cloudy server providers.
Systemd user services start when the user logs in. But, you can make a user’s services start on boot, before they log in, by enabling “lingering” for that user. This is done with loginctl enable-linger $user. That’s how I use Syncthing with systemd and it works great.
Thanks Ifam, I presume this needs the unique syncthing user that I have set up just for syncthing? I’m wondering if this will enable lingering for all services associated with the user at boot or just syncthing?
Final update now I’ve had time to get around to looking at Syncthing again.
It turns out that network.target in systemd was failing silently, no errors in journald or any other system logs. My solution was to install nmcli and remove the connection permissions for both ethernet and wifi (if you’ve a wireless interface). I’ve no idea why there were permissions in the ethernet connection config for network-manager but there you go.
The systemd services for syncthing obviously rely on network.target but never get started. More of a personal remark than advisory, but I’ve now pulled Ubuntu Server off two of my VPS’s and moved to Devuan 2.0. Things just run so much more smoothly, logs are in the right places, errors easily found (okay, only had one due to my own mistake). I’m really failing to see how systemd has made any improvements Linux at all.
Thank you for the support guys, and thank you for Syncthing, it’s running well (just one issue I’m about to post about but probably something I’ve not configured correctly).
