API does not return addr field even if ghash exists in LMDB database

[yobyot]

Hello,

I would appreicate any suggestions on how to resolve the following issue shown in the attached screenshot.

In the screenshot, I have used Postman to request from the Recorder API a series of fields, including addr. As you can see in the lower portion of the image, ghashes are returned but no addr fields are returned.

However, an ocat --dump returns a ghash for the location.

I've restarted Recorder several times and rebooted the VM it runs in as well.

This was working and stopped. A search of the logs shows that each Postman request generates the following log entries, which I think is some kind of error:

Nov 11 21:47:30 iot ot-recorder[3123]: http: GET /api/0/locations
Nov 11 21:47:30 iot ot-recorder[3123]: gcache_json_get: mdb_txn_begin: (-30783) MDB_BAD_RSLOT: Invalid reuse of reader locktable slot

Thanks in advance.

[jpmens]

Something went wrong somewhere, and you are right, that is an error, but we ought to be able to recover from it.

0. Stop ot-recorder
1. In your configured OTR_STORAGEDIR there's a ghash/ directory. Copy (don't move) that aside please for backup.
2. Then remove (yes, rm) the ghash/lock.mdb file, leaving data.mdb in place.
3. Initialize the backend store (this is non-destructive) using ot-recorder --initialize, possibly specifying the path to your OTR_STORAGEDIR directory if necessary with -s. The lock.mdb file should be created and the timestamp of the data.mdb should be unchanged.
4. Restart ot-recorder

[yobyot]

Thanks, @jpmens.

This appears to have worked, though as you can see in the screenshot below, the timestamp of data.mdb was changed to match the timestamp of the new lock.mdb.

Is there anything else I might try to get at the cause of this issue? It's not especially practical to use Recorder for my use case if it randomly stops providing consistent results via the API and requires manual intervention to reset the ghash database and/or its locks.

[jpmens]

Glad it's working again.

We've experienced the situation with the lock file only very sporadically over the last years, and it's difficult to reproduce. It has been known to happen on SIGKILL of the recorder process and when two recorders are mistakenly launched simultaneously.

[yobyot]

Thanks for your help.