Khairunnisah Khairunnisah
Everything went smooth until I try to update publication status from draft to public.
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 to be restarted. This is common in new installations (we are investigating why right now, in the hopes of addressing this in an upcoming release). You will know this is the problem if you look in the error logs and see a message like, "No Gearman worker available that can handle the job."
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
If you have already installed and configured Gearman, then it's likely it just needs a restart. You can check whether or not the job scheduler and its worker is running as expected with:
- sudo systemctl status atom-worker
To restart the atom-worker, see:
sudo systemctl restart atom-worker
Some notes on this:
As noted above, 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.
--
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/f488a9e7-c191-4f3a-a44b-14517034434cn%40googlegroups.com.
Dan Gillean
Thank you.The problem is already solved by creating this service /usr/lib/systemd/system/atom-worker.service.It seems in atom 2.4 up to 2.6, atom-worker service is created automatically.Meanwhile, in atom 2.6.4, we should create it manually.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/36d91170-648e-4935-8e5c-9daeb0e73be6n%40googlegroups.com.