Minimum amount of log file handling we can possibly get away with?

All the useful patterns of running syncthing in the background on Windows discard the log output, and there’s no real practice around capturing stdout/stderr to log files as is fairly common under Unix. Hence the continuing confusion about where to get log data when asked. So as much as I loathe handling log data to files (I really do think that’s something better done by the OS), I think it’s necessary at least under Windows.

So I started by adding a -logfile flag, which gets swallowed by the monitor process who then simply redirects the regular log data to the named file.

The question is, what more must I do to make this acceptable?

Rotate log files per time or size? Or per program start? What’s the expected pattern here, primarily on Windows? (cc @AudriusButkevicius)

(I don’t want to implement a full syslog-ng as part of this :grin:)

I guess truncate the log on start is more than enough.

Also, perhaps we’d want to tone down UPnP messages as that seems to be the only thing producing 3 lines every 30 minutes, otherwise I don’t see how the file could blow up.

Window’s itself has this evil CBS.log which grows indefinitely and though gets rotated usually fills up my SSD before it decides to clean it up.

Though I suggest to make -logfile is only available on Windows, not to encourage its use elsewhere.

Makes sense. Pushed two more commits to https://github.com/syncthing/syncthing/commits/windows-log-file.

I guess truncate the log on start is more than enough.

Good idea, then the guide to getting it running as a service can recommend a restart.

But… this leaves it possible that the error is gone when the admin checks. So maybe one old log file should be kept.