Hello, I have used Syncthing for Windows for a long time with excellent results, I am diving into setting up Syncthing on a Debian based distro (I am not a Linux person so its all fairly new to me). So far so good, but I noticed that the systemctl ExecStart line has the argument -no-restart enabled. I had a need to troubleshoot something and enabled logging, which is when I found the -no-restart argument in place. I had to remove this argument to add logging to a file, using an override.conf to change the ExecStart line. My logging is working, but now I wonder why the systemctl entry has no-restart in the first place…I tried searching around the forums and the internet, and didn’t find a good answer as to why it would be needed or if it is OK to remove this argument for Linux based systems. Reading up on the what the no-restart switch does in the Syncthing documentation, it would seem that the features disabled by this switch are probably beneficial for a headless setup where I wouldn’t want to be babysitting it constantly to restart the service. I’m sure there is some reason it is there by default and this is what this post is about. Does anyone happen to know why this option is enabled by default and if I can/should remove this argument for daily operation?
When run by systemd the babysitting is handled by systemd, so restarts managed by Syncthing are not required. Your best bet is probably to use journalctl or syslog to manage the logs.
Failing that, removing -no-restart won’t have any significantly bad effects. You can run it that way too.
Well, suspend, stop and other systemd features might not work properly as it would be suspending the monitor process not the actual syncthing process.
Thanks! I am getting this going on a Raspberry Pi and I was looking in to why it would stop tranferring after around 30 minutes. When I removed the -no-restart option from the service it then ran non-stop since my first post (~2 hours). I suspect limited resources are causing some issues that systemd is unable to detect. Syncthing’s detection is able to catch and recover from this so I plan to leave this feature enabled. Thanks for the heads up @AudriusButkevicius , I will keep this in mind. So far, commands like “service syncthing@syncuser stop/start” still work fine, it seems to stop/start all running syncthing processes and not just the monitor process. I was more worried about long-term effects as I plan to leave this guy unattended for long periods of time.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.