Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic error log sending to dev. team #959

Closed
Ruffio opened this issue Nov 13, 2014 · 5 comments

Comments

Projects
None yet
5 participants
@Ruffio
Copy link

commented Nov 13, 2014

Following this project from the sideline (by watching this git) I see a lot of sending back and forth error logs. Why not implement an option (like many others do), where error logs are sent automatically to a central repository? This could be both backend and frontend. This option should be an option so its possible to 'not to participate'. This is not an uncommon feature as a lot of software gives the user the opportunity to participate in making the software better/more stable. The user should at any point be able to see what have been sent. Then when reporting bugs here at Github, only a/multiple reference numbers is enough to post with a description of the situation.

@AudriusButkevicius

This comment has been minimized.

Copy link
Member

commented Nov 13, 2014

Great idea I think we did discuss this before and the problem was that somebody has to go through the logs as they arrive.
As far as I understand you do not suggest someone to dig through the logs, and only respond when someone posts a log id?

@Ruffio

This comment has been minimized.

Copy link
Author

commented Nov 13, 2014

To begin with yes, only respond if someone posts the logid. Just to make it
easy for users to report bugs/incidents.
It will then also make it easier for developers to see if others have
experienced the same but just not reported it (by searching for a specific
string in the logs)

Later on maybe a more proactive approach could be followed.
If you as a developer begins to see a lot of error logs with the same
details from different users, then there is a pattern which could indicate
a bug.

Is it just a suggestion.

Venlig hilsen Rasmus Christiansen

2014-11-13 11:28 GMT+01:00 Audrius Butkevicius notifications@github.com:

Great idea, and as far as I understand you do not suggest someone to dig
through the logs, and only respond when someone posts a log id?


Reply to this email directly or view it on GitHub
#959 (comment).

@kozec

This comment has been minimized.

Copy link
Contributor

commented Nov 13, 2014

Just one thing: If implemented, this should be off by default. Syncthing log is full of filenames on all my machines and I can't imagine anything what dares to call itself private or secure spitting my filenames to some random place on the Internet.

@Ruffio

This comment has been minimized.

Copy link
Author

commented Nov 13, 2014

I agree. It should be 'opt-in'.

Just one thing: If implemented, this should be off by default. Syncthing
log is full of filenames on all my machines and I can't imagine anything,
what dares to call itself private or secure, spitting my filenames to some
random place on the Internet.

@calmh

This comment has been minimized.

Copy link
Member

commented Nov 13, 2014

I could see an option where you enable a certain troubleshooting mode, it uploads logs to some location (default https://debug.syncthing.net/ or something, configurable in the same way the discovery server is) and gives you back a message

Saved logs! Tell the developers to look at log ID 1234. To view them yourself, visit this URL containing a magic authentication token...

Perhaps with an option to do this automatically if syncthing crashes or panics.

@calmh calmh added the enhancement label Nov 13, 2014

@calmh calmh modified the milestone: v1.0-maybe Jan 15, 2015

@krozycki krozycki self-assigned this Mar 16, 2015

krozycki added a commit to krozycki/syncthing that referenced this issue Mar 31, 2015

krozycki added a commit to krozycki/syncthing that referenced this issue Apr 6, 2015

krozycki added a commit to krozycki/syncthing that referenced this issue Apr 6, 2015

krozycki added a commit to krozycki/syncthing that referenced this issue Apr 27, 2015

krozycki added a commit to krozycki/syncthing that referenced this issue Apr 27, 2015

krozycki added a commit to krozycki/syncthing that referenced this issue Apr 27, 2015

krozycki added a commit to krozycki/syncthing that referenced this issue Apr 27, 2015

krozycki added a commit to krozycki/syncthing that referenced this issue Apr 27, 2015

krozycki added a commit to krozycki/syncthing that referenced this issue Apr 27, 2015

krozycki added a commit to krozycki/syncthing that referenced this issue Apr 27, 2015

krozycki added a commit to krozycki/syncthing that referenced this issue Apr 27, 2015

krozycki added a commit to krozycki/syncthing that referenced this issue Apr 27, 2015

krozycki added a commit to krozycki/syncthing that referenced this issue Apr 27, 2015

krozycki added a commit to krozycki/syncthing that referenced this issue Apr 27, 2015

krozycki added a commit to krozycki/syncthing that referenced this issue Apr 27, 2015

krozycki added a commit to krozycki/syncthing that referenced this issue Apr 27, 2015

krozycki added a commit to krozycki/syncthing that referenced this issue Apr 27, 2015

krozycki added a commit to krozycki/syncthing that referenced this issue May 4, 2015

krozycki added a commit to krozycki/syncthing that referenced this issue May 4, 2015

@calmh calmh removed this from the v1.0-maybe milestone Nov 17, 2015

@calmh calmh modified the milestone: Unplanned Jan 1, 2016

@calmh calmh removed this from the Unplanned (Contributions Welcome) milestone Feb 11, 2018

calmh added a commit to calmh/syncthing that referenced this issue May 9, 2019

lib/ur: Implement crash (panic) reporting (fixes syncthing#959)
This implements a simple crash reporting method. It piggybacks on the
panic log files created by the monitor process, picking these up and
uploading them from the usage reporting routine.

Internally this is known as "panic uploading" but the user facing term
is "crash reporting" as this is more mainstream.

This becomes a new usage reporting version. I've added strings to the
GUI to the effect that usage reporting includes crash reporting.

The method and server side is trivial; panic logs are uploaded under
their SHA256 hash, with a HEAD request first to avoid sending the entire
log multiple times. Actually doing something useful with this data is up
to the operator of the crash receiver.

A new config value points to the crash receiver base URL, which defaults
to "https://crash.syncthing.net/newcrash" (following the pattern of
"https://data.syncthing.net/newdata" for usage reports, but allowing us
to separate the service as required).

@calmh calmh closed this in 42ce6be Jun 11, 2019

@calmh calmh added this to the v1.2.0 milestone Jun 11, 2019

@calmh calmh changed the title Feature request: Implement posibility for automatic error log sending to dev. team Automatic error log sending to dev. team Jun 11, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.