So basically as soon as a crash happens, a crashlog is generated and send to the server. The links you posted describe precisely what the log consists of: (The following is cited from https://docs.syncthing.net/dev/crashrep.html#report-format)
The report consists of the following:
One line containing the Syncthing version, exactly as reported by syncthing --version. A leading timestamp and log level may be present but is ignored.
Zero or more lines of plaintext data that is for human consumption only. The reports that Syncthing itself sends will have zero lines here, but one could include a report of what happened, log extracts, etc. here barring any privacy issues on the sender’s behalf.
A line beginning with the words Panic at followed by a timestamp in RFC3339 format.
The panic backtrace as printed / formatted by the Go runtime.
If you’re interested in what the “panic backtrace” contains: That is pretty much a list of all goroutine’s (similar to threads) and a list of all functions that they recently executed (or are currently executing), it’s used to “trace back” what a thread/routine was doing prior to the crash. These backtraces only contain code information and not data that is specific to your syncthing instance (at most, one could figure out what features you’re using/not using based on the trace).
They’re saved as a file in the syncthing config directory, but removed after a while. That’s also explained in the link above. Every crash report is send, unless reporting is disabled.
So, I understand your answer to my question
this way:
The user needs to check the syncthing config directory manually from time to time and have a look at the filedates/-times of the saved reports to see if and when crashreports are sent.
I’m gererally not interested, what is sent (but if, I could take a look at the files then as you said), but I’m very interested IF all the machines sending crashlogs once in a year or a month or day.
If you want to know when syncthing crashed, check the directory for crash files. It also logs things to the console as it reports them (I believe), so check your logs.
Having a thing that shows crash reports or times when crashes that is just useless clutter in the UI for the curious.
Nope, its not useless clutter. Its helpful information for the users, which do not have access to the console/directories. (given, that it is next to the logs menu, and not an annoying popup or something which wants to talk to you…)
But its fine, when someone is interested in checking the “life-status” of their syncthing services, they should look at the logs.
I guess, I never will find a crashlog, because I cannot watch the dir every day and don’t know the lifecycle of those files.
It is really not useful information to the users, it’s a bunch of stacktraces in opaque language in a codebase they potentially never seen and potentially will never see.
Also, you don’t need to know about the crash log, it’s not meant for you, it’s meant for us.
If you are some sort of enterprise user then, sure, definitely. You should be monitoring your Syncthing deployment, both via the logs and something that verifies that it’s up and running properly. We yell quite loudly about panics/crashes in the log output, and now also note that reports are being made, if/when they are.
If you are a regular home user you probably just want things to work. I think it’s an “if a tree fell in the forest and nobody heard it” kind of situation. Syncthing restarted automatically. If you didn’t notice this happening, was there even a crash, as opposed to an internally handled error condition? Reporting it upwards so that it doesn’t happen again is good, though.
Reporting it upwards so that it doesn’t happen again is good, though.