I’ve used NSSM in past insulations and have set it up for one other person and haven’t had any problems.
A problem: Syncthing doesn’t go to the background. I can’t get the command line back or close the PowerShell window unless I kill the Syncthing process. Is there a recommended way of doing this? I checked the command-line options and nothing stood out in a quick review.
Just curious, why not make it work like a standard Windows service? I could use NSSM to do it manually, but that may make upgrades fragile?
NSSM is certainly an option, but I think it’ll be less complicated and avoids permissions issues if Syncthing is launched by Windows Task Scheduler instead.
Depending on if you’d like Syncthing to run 24/7 even when you’re not logged, enable the option to start at login time or Windows boot time.
Syncthing’s official docs has a section about this very thing: Run at user log on or at system startup using Task Scheduler
Take a look at the issues list for Syncthing Windows Setup and you’ll see that it used to use nssm but stopped due to anti-malware app paranoia. (It now uses shawl for installing the service instead of nssm.)
Oops, all of you are right about the challenges of running it as a service. It is ideal to run during the user’s session, using the user’s account to access files.
Regarding WMI: I stand by the fact that blocking WMI process creations for the current user is pointless and doesn’t improve security (and in fact, needlessly prevents a legitimate use of WMI).
I have no basis to disagree. Microsoft Defender blocking WMI appears to be a new reality for corporate users, and it wouldn’t surprise me to see this creep into other protection tools or to home users.
…I think it’ll be less complicated and avoids permissions issues if Syncthing is launched by Windows Task Scheduler instead.
That makes a lot of sense! It could be triggered by when my own account logs in.
Depending on if you’d like Syncthing to run 24/7 even when you’re not logged, enable the option to start at login time or Windows boot time.
I feel it’s best for it only running when I am logged in.
Oops, all of you are right about the challenges of running it as a service. It is ideal to run during the user’s session, using the user’s account to access files.
This depends on the use case. For example, I install Syncthing as a service on a multi-user computer and I sync folders in several different user profiles. Installing as a service means that files get synced even when there are no users logged on.
OK…
I wrote a small utility tool for the next version for per-user installs that starts and stops Syncthing for the current user…
https://github.com/Bill-Stewart/stctl
This doesn’t use WMI, and it starts syncthing.exe
using “below normal” priority in a hidden window. Download location:
https://github.com/Bill-Stewart/stctl/releases
The next version of Syncthing Windows Setup will use this tool instead of the StartSyncthing.js
and StopSyncthing.js
scripts.
You can test now by copying stctl.exe
into the Syncthing installation directory. To start Syncthing:
stctl --start
or to stop:
stctl --stop
(The saga of anti-malware “whack-a-mole” continues…)
Thank you. Confirming that this seems to work, and Syncthing is running and scanning files for a first-time sync.
Thank you for testing! The stctl
utility will replace the start and stop WMI scripts used in earlier versions.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.