Skip to first unread message
John Thiesen
Nov 2, 2021, 2:04:17 PM11/2/21
to AtoM Users
We're on AtoM 2.6. I've noticed that there are a couple of places where Subject browse produces "500 Internal Server Error." I'm thinking there must be a couple of subject terms that are corrupted
You can reproduce the error at https://archives.mhsc.ca/index.php/taxonomy/index/id/35 by using "wood*" or "Yoder*" in the search box. This happens also if the user is browsing up or down the list and happens to hit one of these terms. I've run through the entire list of terms elsewhere in the alphabet and did not find additional bad terms
Is there any way I can delete the 2 corrupted terms? Or even find out what they are?
Dan Gillean
Nov 2, 2021, 4:17:01 PM11/2/21
to ICA-AtoM Users
Hi John,
If you haven't already, I'd suggest taking a look at the webserver error logs to see if the related error message might provide more information on what's causing this 500 error. Feel free to share what you find here if you're uncertain how to proceed. For checking the error logs, see:
After that, the first thing I would suggest that you try is running a couple maintenance tasks that can fix common corruption issues - namely, rebuilding the nested set and generating slugs.
If a search is causing the 500 error, then there could also be an issue with the search index - hopefully the error logs will tell us more, but you can get some basic information on the status of your index with this task:
And you could try re-indexing - but be aware that this can be a long-running process that will make your content temporarily unavailable while it runs, so it's generally best to start a re-index outside of business hours, or even on a Friday so it can run over the weekend for a large site. See:
(That said, kicking off a reindex only to return on Monday to discover it failed due to whatever is causing this error would not be great, so you may want to try the other steps in this thread first, and if they don't fix the issue, report back on what you find in the error logs and from the search:status task)
Whether you choose to re-index or not at this time, after any of the above steps I would clear the application cache, restart PHP-FPM, and do a quick test to see if that happened to resolve the issue.
- Clear application cache: https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/clear-cache/
- Restart PHP-FPM: https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/troubleshooting/#restarting-php-fpm
- This command depends on the PHP version you are using, so if you're not using 2.6, be sure to check the correct version of the documentation to match your AtoM major release version
If that works - great! If not, then we do have some MySQL queries that might be helpful for identifying data corruption in our Troubleshooting documentation. You will need to access the MySQL command prompt to run the queries - instructions on how to do so can be found here:
The data corruption check queries can be found here:
These queries currently mainly help identify problems with information objects (i.e. archival descriptions), but may still help to uncover related issues. If you do find issues, that section of the documentation has a few follow-up recommendations depending on what you find.
Otherwise, please share with us anything relevant you discover during your investigation, and we can attempt to provide further suggestions based on that.
Good luck!
he / him
--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/cf2b9ec8-f14d-4bff-b712-c2dba5a0b0c4n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages