Oakham School Archives
Dan Gillean
Any time you encounter a 500 error, the first thing we recommend is to check the webserver logs for more information on the nature of the error.
If you have followed our recommended installation instructions, you can check the most recent error log entries with:
sudo tail -f /var/log/nginx/error.log
See:
Feel free to share any related error message you find here if you're not sure how to proceed, and we will try to offer suggestions on next steps. However, I suspect that the issue is simply that the job scheduler needs a restart. This is a common issue in new installations that we're currently investigating, but in the meantime the solution is pretty easy to apply if you have access to your server.
There are several tasks in AtoM that can take a long time to execute - longer than the default 1 minute timeout limit that most browsers impose to prevent requests from exhausting all system resources. To avoid the browser timeouts from terminating long-running processes midway through (and potentially causing data corruption), AtoM uses Gearman as a job scheduler to perform these tasks asynchronously in the background. This way, the user can keep using AtoM while the job runs, and the length of the job is not bound to 1 minute or less.
Examples of things that AtoM currently uses the job scheduler for:
Imports (both CSV and XML) from the user interface
Exports from the clipboard
Moving a description from one parent to another
Generating finding aids and reports
Handling DIP uploads from Archivematica
And more!
The details for installing the job scheduler (Gearman) can be found here:
If you have already installed and configured Gearman, then it's likely that the job scheduler simply needs a restart. 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."
To restart the atom-worker, see:
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 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.
If none of these suggestions help to resolve the issue, and/or this is not what you find in the error logs, then please let us know what you discover, as well as more information about your installation (Operating system, PHP version, etc) and we can provide further suggestions.
Cheers,
--
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/5c0cf563-6ab8-4675-8ead-dda98d039a1en%40googlegroups.com.