500 Internal Server Error al navegar por Lugares y materias

305 views
Skip to first unread message

Mercedes Jiménez Bolívar

unread,
Mar 9, 2021, 8:03:16 AM3/9/21
to AtoM Users
Hola, amigos.
Tras la instalación de la versión 2.6.2 de AtoM nos da  error  "500 Internal Server Error" al intentar navegar por las taxonomías de lugares y materias, ¿nos podéis ayudar a averiguar qué hemos hecho mal?
Muchas gracias
Mercedes Jiménez Bolívar

Mercedes Jiménez Bolívar

unread,
Mar 9, 2021, 8:11:12 AM3/9/21
to AtoM Users
Y nos da error también al intentar añadir un nuevo documento de archivo, registro de autoridad...

Dan Gillean

unread,
Mar 9, 2021, 11:11:33 AM3/9/21
to ICA-AtoM Users
Hola Mercedes, 

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.

Checking the Nginx error log  

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. 

Restarting the job scheduler

Given that you are seeing multiple errors for common actions, I suspect that the job scheduler may need to be configured, or restarted. The details for installing the job scheduler (Gearman) can be found here: 
If you have already installed and configured Gearman, then it's possible 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:
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. 
Running common maintenance tasks

If that doesn't resolve the issue, you can try running some of AtoM's common maintenance tasks to see if they help resolve the issue - for example, rebuilding the nested set, generating slugs, clearing the application cache, restarting PHP-FPM, and re-indexing.
  

All of the following commands should be run from the root AtoM installation directory - if you have followed our recommended installation instructions, then this is typically: 

  • /usr/share/nginx/atom

If the commands won't run and you've confirmed you are in the right directory, try running them as the www-data user - this is the user to whom we assign all filesystem rights when installing and configuring AtoM. To do so, simply precede the commands below with sudo -u www-data. 


Rebuild the nested set: 

Generate slugs

Clear the application cache

Restart PHP-FPM

If you have memcached installed, it is good to clear that cache as well. This command should not have any ill effects if you don't have memcached installed, so you can always try it out: 

Repopulate the search index

  • php symfony search:populate

  • See: https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/populate-search-index/

  • Note: If you have a lot of records, this task can take a long time to run, and will make records temporarily unavailable in the user interface as they are reindexed. Best to run this after business hours. However, you can also use some of the task options to reduce the time it takes by limiting how it runs - for example, using the --update option will not make existing records unavailable as the task progresses (it will progressively replace the index rather than deleting it first). The --exclude-types option can be used to target just certain entity types, rather than all of them, and the --slug option can be used just to target specific records, taking the slug as input. See the documentation for further details and options.

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, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory
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/dde988f0-31a2-4ebb-b775-67033ddde13an%40googlegroups.com.

Domi Marquez

unread,
Mar 10, 2021, 4:05:26 AM3/10/21
to AtoM Users
We have this reg in the logs:

2021/03/08 21:08:38 [error] 655#655: *367 FastCGI sent in stderr: "PHP message:  [wrapped: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'RECURSIVE aas AS
      (
        SELECT tb1.id, tb1.parent_id, 1 as lev
      ' at line 2]" while reading response header from upstream, client: 150.214.40.44, server: archivo. xxxxxxx.org, request: "GET /index.php/aclGroup/indexActorAcl/id/100 HTTP/1.1", upstream: "fastcgi://unix:/run/php7.2-fpm.atom.sock:", host: "archivo. xxxxxxx.org", referrer: "http://archivo.xxxxxxx.org/index.php/aclGroup/index/id/100"



Dan Gillean

unread,
Mar 11, 2021, 9:37:21 AM3/11/21
to ICA-AtoM Users
Hi Domi, 

Most often when I see errors of this kind it is because of 2 things - though we will try to rule out a few other common issues as well. Generally, it is either because the wrong SQL modes are set in MySQL during installation - particularly the STRICT_TRANS_TABLES mode which is known to cause issues - or else there was an issue during an upgrade (such as forgetting to run the upgrade task, or upgrading with some data corruption present). 

First, let's rule out a few of the easier (though less likely) possibilities. First we will make sure there's not an issue with the filesystem permissions, although I suspect this has more to do with MySQL. Just to be sure, we'll reset the filesystem permissions with the following command: 
  • sudo chown -R www-data:www-data /usr/share/nginx/atom
Next, I would suggest checking  the SQL modes set in MySQL, and disabling/removing STRICT_TRANS_TABLES if it is enabled. I believe this might be enabled by default in 5.7 and later - however in the MySQL section of the installation docs for 2.6 we recommend setting different default SQL modes. See the bottom half of this section:
If you want to check or change the SQL modes of an installation, the following page might help:
If you're new to using the MySQL command prompt, we have basic instructions on how to access it, and how to find out your MySQL credentials if you don't know them, here:
You might also want to check the database name and user you set up during installation, and make sure they match. The link above has suggestions for how to check this. We also show you how to configure a different users, as well as configure database user permissions, in this section of the installation docs (near the bottom):
The most important thing will be to make sure that your primary database user, who has all the correct credentials, is the same one you configured in the web installer during installation! You can double check which user is set in the config/config.php file. See:
Finally, we can also run a few maintenance tasks to resolve common issues, and/or make sure it's not something minor. 

Let's first rebuild the nested set, which is used to manage hierarchical relationships in MySQL's table-based structure. From AtoM's root installation directory, run:
The Generate slugs task will ensure that any of the core entity types that are missing a slug for some reason have one added, which can often help resolve issues caused by timeouts (such as during large imports, etc). 
Clear the application cache: 
Rebuild the search index: 
And, remember to clear your browser cache before retesting, or test in an incognito / private browser window, where the cache is typically disabled by default, to ensure you're seeing the most up-to-date version of the page! 

If this still doesn't help, then my next suggestion would be to check for database corruption. We have a SQL command in the Troubleshooting documentation that can check for the most common forms of database corruption, which is usually caused by timeouts during large operations. See: 
The last thing we can check is whether or not a schema migration was missed during an upgrade. This can happen when the upgrade task is not run correctly, meaning that the database schema is still one or more versions behind the current release. Check the full version number in Admin > Settings > Global - or alternatively, you can use the following task to check the full version number from the command-line: 
The number for the 2.6.0 release is: 2.6.0 - 185. This second number after the dash is the database schema version. These typically only change in major releases - any time a new feature is added that requires changes to AtoM's database, a schema migration is included that, when users upgrade, will apply the changes and ensure that the database schema matches the changes included in the release. If users forget to run the upgrade task, there can be mismatches that cause issues. 

Because there are no new features requiring database schema changes in our minor releases, this number should be the same for 2.6.1 and 2.6.2. If  you are running 2.6.x and your schema version number is lower than 185, then this may be the issue - let me know. Similarly, if you are running an earlier version of AtoM, let me know the schema version you see, and I can check it against previous releases. If there is a mismatch, I'll talk to our team about the best way to resolve this. 

Let us know what you find, and if any of this helps to resolve the issue! 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory
he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/efb09ba4-d13e-4987-95e3-45269b900c27n%40googlegroups.com.

Domi Marquez

unread,
Mar 15, 2021, 9:28:15 AM3/15/21
to AtoM Users
Hi Dan and thanks.
I try all of this thinks and we have the same problem. 

I think we make a mistake when i create the database because:
When i did mysql installation i changed the collation of the databases from utf8mb4_0900_ai_ci to utf8mb4_general_ci because failing with this collation.

I saw that message: ERROR 1273 (HY000) at line 1: Unknown collation: 'utf8mb4_0900_ai_ci'

When i open /etc/mysql/conf.d/mysqld.cnf to add:
[mysqld] sql_mode=ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION optimizer_switch='block_nested_loop=off'
I can´t start mysql again after adding that lines.

All the other thinks that you said i think is correct.
  • www-data is the owner of the directory and i even changed all permissions to 777 to make sure that wasn't the problem.
  • I can access from promt with my database user
  • The website is working but when we try to acces to places or other places we continue looking "Error 500"
  • Php symfony tools:get-version is 2.6.2 v184

Thank you so much for your help.

Dan Gillean

unread,
Mar 15, 2021, 1:12:35 PM3/15/21
to ICA-AtoM Users
Hi Domi,

I have two thoughts, that are related and might be resolved at the same time. 

First: have you installed MySQL 8.0 for 2.6? Please note that we upgraded MySQL between 2.5 and 2.6. See:
This version is the first to support the new collation format, so if you haven't upgraded as expected, this could be the reason that the suggested collation format is failing. Hopefully this might help you properly set the SQLmodes as well. In general, it's because of these type of core dependency changes that we always recommend that upgrades are performed by installing a new version of AtoM alongside your old installation and then migrating the data, rather than trying to upgrade in place!

It looks like at least one database schema migration has been missed - you list your version as 2.6.2 v184, but 2.6.0 should have schema version 185. This can happen when the upgrade task is not run during an upgrade - but also, if you still had MySQL 5.7 in place, it's possible that one of the 2.6 schema migrations didn't properly execute since it relies on the new CTE expressions available in MySQL 8! 

I'd suggest that you repeat some of the upgrade steps again, to see if we can get the task to run correctly and get your database schema version to v185. You will need to make sure your data is backed up outside of AtoM, since we will first purge all data, before running some tasks and then reloading it! See our backup docs here:
Once you've made a backup of the database, you can then try to run the tools:purge task (WARNING: this will delete all data in AtoM, so make sure you have that backup!), then drop and recreate the database, and  then reload your data and try the upgrade task again (as per the upgrade docs). Remember to run all the recommended maintenance tasks again after - populate the search index, clear the application cache, restart PHP-FPM and memcached, etc... Check your database version again and see if it's v185 - and whether any of the issues you are encountering have been resolved! 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory
he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/7dd1d92b-c2b1-4564-8752-b4968654abc9n%40googlegroups.com.

Domi Marquez

unread,
Mar 16, 2021, 5:35:55 AM3/16/21
to AtoM Users
Thank you so much Dan, thats was the problem, we was using mysql 5.7.

I upgraded the mysql and reinstall AtoM and start to work.

Thank you so much!!!

Domingo Márquez Soto

unread,
Apr 7, 2021, 5:45:47 AM4/7/21
to AtoM Users
Well Dan, I'm here again.
We resolve all the problem but when we try to create a realationship we see the same problem: 500 Internal Server Error.

Dan Gillean

unread,
Apr 8, 2021, 9:47:19 AM4/8/21
to ICA-AtoM Users
Hi Domingo, 

Oh no!

Let's start by collecting some information. 
  • What is the full version number of your AtoM installation after the recent database changes - as seen in Admin > Settings > Global?
  • What version of PHP are you using with AtoM?
  • What is the error message you are seeing in the webserver Nginx logs?
  • When you switched to MySQL 8, how did you do so? did you try upgrading in place, or install a new version of AtoM and follow the Upgrade instructions, or something else?
  • What is the default culture of your installation?
  • If you followed the upgrade instructions, did you:
    • Remember to drop and recreate the database before loading your sqldump?
    • Remember to run the upgrade task after loading your sqldump?
    • Remember to run some of the maintenance tasks (such as rebuilding the search index and clearing the application cache) after?
  • Does your installation have a custom theme in place?
  • If yes, did you remember to check the Upgrade instructions for any relevant notes on Custom themes and upgrades, and apply the recommended changes?
Hopefully with a bit more information, we can provide further suggestions for you! 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory
he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/3af7fa4d-4e81-4ca0-bb4c-21b563287fb9n%40googlegroups.com.

Domingo Márquez Soto

unread,
Apr 9, 2021, 8:54:41 AM4/9/21
to AtoM Users
Hi!!!
Well i start with all your question.

Application version: 2.6.2 - 184
PHP Version : PHP 7.2.24-0ubuntu0.18.04.7
Error log: 2021/04/09 12:41:57 [error] 190#190: *13605 FastCGI sent in stderr: "PHP message: Unable to execute INSERT statement. [wrapped: SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`cmsatom`.`relation`, CONSTRAINT `relation_FK_3` FOREIGN KEY (`object_id`) REFERENCES `object` (`id`) ON DELETE CASCADE)]" while reading response header from upstream, client: 37.134.107.117, server: _, request: "POST /index.php/digitalizadora-de-la-memoria-colectiva-andalucia-espana-2020/edit HTTP/1.1", upstream: "fastcgi://unix:/run/php7.2-fpm.atom.sock:", host: "archivo.ladigitalizadora.org", referrer: "http://archivo.ladigitalizadora.org/index.php/digitalizadora-de-la-memoria-colectiva-andalucia-espana-2020/edit"

When i update mysql i did a new installation following all the steps in https://www.accesstomemory.org/es/docs/2.6/admin-manual/installation/linux/ubuntu-bionic/

In this moment we are working with the GUI in english but the people that are introducing info are writing in Spanish.

We are  using the default theme

Domingo Márquez Soto

unread,
Apr 9, 2021, 9:01:14 AM4/9/21
to AtoM Users
I'm looking that when i try to create the relationship in the field Authorized form of name I can not see anything but i think i must see something.

Dan Gillean

unread,
Apr 9, 2021, 11:11:14 AM4/9/21
to ICA-AtoM Users
 Hi Domingo, 

It's hard to say what's going on here, but in the current version of AtoM, you will get a 500 error with a similar message if you try to add a relationship to an authority, and do not select a related authority. If you are not picking a related authority before trying to create the relationship, then this is expected. Note that we have recently had a community pull request that would change the behavior so incomplete relationships are skipped instead of throwing an error (so that other data entered on the actor is not lost). See: 
In the meantime, if you are saying that you can even SEE your related authority records in the drop-down menu to select them, then I suspect that this might still be an i18n issue. The drop-down field is likely filtering based on the current user interface culture, so if your other authorities are created/saved in a different culture and don't have translations, then this could cause them not to show up. 

For example: If your users are entering Spanish data while using the English UI, then AtoM will save the records with a source_culture of en, since it expects English content when it is entered in the English user interface. If someone else tries to add a relationship while in the Spanish interface, then in this case you may not see the expected authority records in the drop-down menu. 

You could try testing this out with a few different cases - 
  • try creating two authorities while in the English interface, and then see if you can create a relationship between them
  • try creating two authorities while in the Spanish interface (i.e. use the Language menu to change the UI before entering edit mode) and do the same
  • try creating a relationship between one authority created in English, and another in Spanish
  • then add translations for these records, and try again
  • etc
If you do so, please let us know what you find!

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory
he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/ffc92266-5473-486a-b1aa-9e580c596c52n%40googlegroups.com.

Mercedes Jiménez Bolívar

unread,
May 5, 2021, 2:41:57 PM5/5/21
to AtoM Users
Hola, Dan.

Los problemas se resolvieron y estamos muy agradecidos a vuestra ayuda. 
Resolución: Hizo falta actualizar MSQL y  fallaba la instalación del Gearman Worker.
Ahora a actualizar a 2.6.4.
Muchas gracias. Eres todo amabilidad.

Reply all
Reply to author
Forward
0 new messages