Resolving an issue like this generally requires access to the command-line interface to the installation server itself. If you are not the person who maintains your AtoM installation, feel free to pass this message on to the person who is.
Any time you encounter a 500 error like this, the first thing we recommend is to check the webserver error logs. If you have followed our recommended installation instructions and are using Nginx as your webserver, you can check the most recent logs with the following:
This will spit out the most recent error in the log. If you're not sure what to do with it, you can try searching in this forum, and/or share the message here and we can suggest next steps. But I will also include some general suggestions on possible next steps below.
Job scheduler issues
We use a job scheduler called Gearman in AtoM to handle long-running tasks in the background, so they don't time out in the browser. This handles things done via the user interface such as imports and exports, move operations, publication status updates, finding aid generation, and more. Occasionally, the Gearman atom-worker process crashes, and the job scheduler needs a restart - this would cause the 500 error you see to be returned for any of those long running operations. You will know this is the case if you look in the error logs and see a message like, "No Gearman worker available that can handle the job."
For general instructions on how to restart the atom-worker, see:
If you have followed our recommended instructions, you can restart the atom-worker with:
- sudo systemctl restart atom-worker
Some notes on this:
You can check the status of the atom-worker at any time with:
- sudo systemctl status atom-worker.
This is useful to make sure the restart was successful. When the worker dies, AtoM will attempt to automatically restart it - however, to prevent the system from being caught in an endless loop, we have also added a restart limit - 3 retries every 24 hours. You can reset this fail limit with the following command:
- sudo systemctl reset-failed atom-worker
Then run the restart command again if the previous attempts didn't work.
Common maintenance tasks
Our Troubleshooting documentation also includes a list of common maintenance tasks that can often help resolve many common issues in AtoM - many of them also the result of long-running processes that get interrupted. See these sections:
Also in general, these tasks will not cause issues if there aren't any, and run quite quickly. The one exception to this is repopulating the search index - this allows users to find records in the user interface via searching and browsing. Depending on the size of your database, this can take anywhere from minutes to, in extreme cases (for very very large installations) days to run - and while running, records are not available via the user interface. For that reason, we recommend running the search index updates outside of normal business hours, to avoid disruption.
Tasks I would recommend you try running, in this general order:
- Generate slugs
- Rebuild the nested set
- Clear the application cache
- Restart PHP-FPM
And then:
- Populate the search index
Instructions and further links for all of these can be found on the Troubleshooting page, linked above.
If that still doesn't work:
If you have tried all of the above and you are still encountering this error, then we will need more information about both your AtoM installation and what led to the error in the first place before we can offer further suggestions. Information that will help us includes:
- The full version number of your installation, found in Admin > Settings
- Whether you followed our installation instructions for your version - and if not, what changes you have made
- Whether or not your installation server meets or exceeds the recommended hardware technical requirements:
- Processor: 2 vCPUs @ 2.3GHz
Memory: 7GB
Disk space (processing): 50GB at a minimum for AtoM’s core stack plus more storage would be required for supporting any substantial number of digital objects.
- Whether or not you have any customizations and/or code changes in place, including a custom theme plugin
- Any information relevant to this issue first appearing - did you upgrade recently? Did someone try to run a big import that failed or similar? Did anything in particular happen that led to these errors starting?
- Tell us about what happened when you tried the recommendations above, and please share with us what you found in the webserver error logs
Hopefully with a bit more information, we can provide further suggestions on next steps.
Cheers,