Hi there, long time user of syncthing on many devices.
The strangest thing just happened with my “main” syncthing machine, which is an ubuntu server that I leave on pretty much all the time.
I got an error in the main log like this:
panic: This file must exist in the db
[monitor] 22:54:15 WARNING: Panic detected, writing to
"/home/chicagobuss/.config/syncthing/panic-20190302-225415.log"
[monitor] 22:54:15 WARNING: Please check for existing issues with similar panic
message at https://github.com/syncthing/syncthing/issues/
[monitor] 22:54:15 WARNING: If no issue with similar panic message exists,
please create a new issue with the panic log attached
[monitor] 22:54:15 INFO: Syncthing exited: exit status 2
[monitor] 22:54:16 INFO: Starting syncthing
A few weird things about this:
This panic file that it mentions never actually got created
When syncthing started back up after this panic, it forgets its normal ID and uses some new one that I can’t figure out where it’s coming from
Now, it appears like I’ve gotten a fresh config.xml file - none of my folders are there anymore!
Googling for this particular error message, literally the only place I can find it is in the sourcecode itself.
How do I get my config file back? Is there a backup somewhere?
It sounds like something wiped out the config directory while syncthing was running. Syncthing doesn’t keep config or keys outside of that, so unless you have a backup yourself it sounds gone.
Not sure what happened but somehow my original config and ID came back. This seems really weird - it’s like my install is switching between two different IDs.
Hmm, I don’t see how that would be possible. I only start it with a small ./start.sh script I put in my syncthing dir, which just starts the binary with nohup and a specific gui address.
That would not be very useful. I looked at the source, which anyone else could also do, and the file referred to is apparently one of those tracked by Syncthing. There is a record that refers to it, but then it does not exist in the database. It means essentially the database is completely toast - as apparently the entire database was erased in the OP’s case. We could say that instead, or prefix any panics from the database layer with something to that effect…
(I'm already not in the best of moods due to no fault of yours so take this for what it's worth... But "Shouldn't ..." or "Why don't you ..." questions are generally tiring for me. If it seems like something that could be improved, see if you can improve it and file a PR and everyone will be happier. Calling on us to defend old decisions on minor details is exhausting in the long run.)
Thanks Jakob. I’m not in a great mood either because I’m coming down with a cold, but if there’s anything I can do to help get more info on what happened in my case I’d appreciate it.
I still don’t understand how I both lost my config.xml file and started using a new ID I’ve never seen before and then got my original ID back again later.
I’m sorry. I should have phrased that better. It was not my intention to point out that the current situation is handled bad. It was more of a question if the name of the file would have helped to clear things up. Which is not the case as you already explained.