In a windowsserver environment i have syncthing runnning as a service. to my mind the downloadlog is written in the usercontext, as soon as syncthing runs as a service the log is not written to anymore. is trhere a workaround? Can i set the location of the log file in the config somewhere
Sorry, but what is DownloadLog.csv? It’s not something that is built into syncthing.
ah, could be its something from synctrayzor which I tried as well.
So, where does syncthing (standalone) write the log to?
It depends. Check syncthing -paths, but that can be overriden by env vars, command line switches and so on.
If you run it as a system service, I think the home directory for system accounts ends up being c:\windows\system32
Thx for your reply: with syncthing -paths i get a result: C:\Users\gur\AppData\Local\Syncthing\syncthing.log
But this logs gives me only systemlogging, but i can’t find anything about filetransfers. I need to find out if and which file was transferred at which time.
Syncthing doesn’t log file transfers specifically. You can enable debug logging and then filter them to find exactly which files have been transferred, but this will require writing some custom scripts or similar to process the logs.
SyncTrayzor has this ability, so simply using it instead may be the easiest solution. Of course, SyncTrayzor is a GUI program and needs to be run in the user context. Is running Syncthing as a service absolutely necessary in this case?
Well yes, it should be unattended, its running on a virtual server. I don’t want to have to login after a reboot so that syncthing is runnig again
How about enabling auto-login (and then lock after timeout if necessary, for security), so that you could start SyncTrayzor and keep it running on a user account this way? Otherwise, the only way will likely be to write some custom scripts to filter the logs.
I wouldnt want to go for auto-login. I’ll try the log.
Where can I enable the log to verbose? I searched the doc, but it’s not giving me hints at all.
You can find it under https://docs.syncthing.net/dev/debugging.html. You will also probably need to take care of the log file rotation that defaults to four 10MB-sized files in Windows, which will be too little for verbose logs. I would suggest to either disable rotation altogether, or increase the number of files. All these can be configured with commandline flags.
tomasz, you are really helpful and actually I feel bad about bothering you, because I think that this tool is not really suited to our needs.
In the document I can’t find the commandlineparameters needed to change the logging.
I tried the ssttrace option “model”, but there was no fileoperation recorded. To my mind the app running as a service will not be able to read the environment variable, because this is in the user context.
I think this is the main issue, the tool is not designed as a service from scratch and I’m trying to find workarounds…
How about running the Syncthing binary in background using the Task Scheduler? This way, it will run in a user context, but it will also be able to autostart on boot before actually logging on. All the details are explained at https://docs.syncthing.net/users/autostart.html#autostart-windows-taskschd.
The command line parameters are explained in the Docs under https://docs.syncthing.net/users/syncthing.html, but to get the newest state you can always just run syncthing --help. To get the logs saved without rotation e.g. on the Desktop, I would do
syncthing -logfile="%USERPROFILE%\Desktop\syncthing.log"
I have never needed to record a full list of downloaded files, so I’m not sure which debug logging will give you the most useful information. I would test various options by enabling and disabling them temporarily through the Web GUI first.
Please be aware that with no restrictions a debug log will easily grow up in hundreds of MBs very quickly, so I would suggest to use some kind of a script that would scrap the old data once no longer needed (i.e. delete the logfile, and Syncthing will continue to write to a new one at the same location).
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.