Support #12508
closedAccess logs for SDILab geonetwork
100%
Description
For some reason the Geonetwork Csw get capabilities is broken: http://geonetwork-sdi-lab.d4science.org/geonetwork/srv/eng/csw?service=CSW&request=GetCapabilities&version=2.0.2
can we access the logs to see what's wrong? and eventually do you know whay's wrong?
Updated by Andrea Dell'Amico over 6 years ago
- Assignee changed from _InfraScience Systems Engineer to Fabio Sinibaldi
The logs are already available at https://geonetwork-sdi-lab.d4science.org/gcube-logs/
Updated by Fabio Sinibaldi over 6 years ago
- Status changed from New to Feedback
Related stack trace seems to be https://support.d4science.org/pastes/46 .. Does it tells you anything? I'll keep investigating.
Updated by Emmanuel Blondel over 6 years ago
Sorry i should have remembered the link of gcube logs.. i had a look to the logs and i got an internal error from geonetwork.. Fabio can you look into this? maybe the db is corrupted, some bad csw bad transaction created this issue. The issue prevents to load the csw get capabilities.. maybe can you inspect the geonetwork db? Thanks in advance
Updated by Fabio Sinibaldi over 6 years ago
It's really difficult to find out the reasons, but some bug reports led me to check language references in the database.
Here a possible hint :
Requests with unknown language (found "cze" and "fra" - correct value seems "fre").
select * from requests where lang not in (select id from languages)
I'm not expert in this part of GeoNetwork, so I'm not sure if this is the actual cause. Please, let us know what you think.
Updated by Emmanuel Blondel over 6 years ago
- Status changed from Feedback to In Progress
- Assignee changed from Fabio Sinibaldi to Emmanuel Blondel
- Priority changed from Immediate to Normal
I will investigate a bit more. Some null entry is causing this issue somewhere.. Do you have possibility to make a dump of the geonetwork backend db?
Updated by Fabio Sinibaldi over 6 years ago
Generated dump file in VRE Folder under "Support Activity" > "12508" (quick link https://goo.gl/7rZPMr).
Updated by Emmanuel Blondel over 6 years ago
In order to better assess what's wrong I would need to access the remote DB. Can this be authorized through online PgAdmin on the e-infra? Thanks
Updated by Emmanuel Blondel about 6 years ago
Hello @sinibaldi sorry to come back so late on that, but this was very low priority on my agenda. Would it be possible to check on the geonetwork db the table languages
and see if some default language is properly set by doing smthg like:
SELECT * FROM languages WHERE isdefault = 'y';
If there is no result, to set 'eng' as default language like this:
UPDATE languages SET isdefault = 'n';
UPDATE languages SET isdefault = 'y' WHERE id = 'eng';`
And restart Geonetwork.
Thanks in advance
Emmanuel
Updated by Fabio Sinibaldi about 6 years ago
Hi Emmanuel,
the Select statement returned the following row (column names in first line), so I guess this part of the configuration is already ok :
"id";"isdefault";"isinspire";"name" "eng";"y";"y";"English"
Updated by Emmanuel Blondel about 6 years ago
Ok, at some point, I think that we need to clean the DB, and start with an empty catalogue, because at some point some publication test during the previous workshop corrupted the DB. @julien.barde@ird.fr I guess you can then regenerate easily your test metadata sheets, let me know if you see any objection For the test Tuna atlas metadata sheets, no needs to regenerate now IMHO.
Updated by Emmanuel Blondel over 5 years ago
- Status changed from In Progress to Closed
Solved with cleaning the DB