Identificación de usuarios-tarda 2 minutos

[Mercedes Jiménez Bolívar]

¡Hola!

Estamos instalando AtoM 2.8.1-193 y se nos presenta un problema con  la identificación de usuarios que os especifico un poco más abajo. 

No sabemos qué hacer.  ¿Nos podéis ayudar? 

¡Gracias!

Mercedes

Contexto donde seha producido el problema:

4 máquinas con sistema operativo Rocky Linux 9.3, actualizadas al día y clonadas unas de otras.

Versión de atom 2.8.1-193, dos con bases de datos convertidas de versiones anteriores, y dos con base de datos inicial

Funcionando como contenedores LXC en el mismo "host"

Aparentemente las cuatro máquinas no muestran señales de mal funcionamiento en mostrar información de Atom, y con tiempo de respuestas inferiores al segundo en peticiones simples.

Problema:

 La identificación de usuario para administradores tarda menos de 1 segundo en una de las maquinas migradas y mas de dos minutos en las otras tres, con errores de gateway timeout y realizando efectivamente su identificación.

Prediagnóstico:

Intento de identificación a las  17:04:26

Registro de error de Apache:

[Mon Apr 08 17:05:26.636958 2024] [proxy_fcgi:error] [pid 3976:tid 4031] (70007)The timeout specified has expired: [client 192.168.93.1:42588] AH01075: Error dispatching request to : (polling), referer: http://gestion.rivero.uma.es/atom/
[Mon Apr 08 17:06:30.091740 2024] [proxy_fcgi:error] [pid 3910:tid 3959] (70007)The timeout specified has expired: [client 192.168.93.1:45292] AH01075: Error dispatching request to : (polling), referer: http://gestion.rivero.uma.es/atom/

Registro de operaciones de Apache:

192.168.93.1 - - [08/Apr/2024:17:04:26 +0200] "POST /atom/index.php/user/login HTTP/1.1" 302 105 "http://gestion.rivero.uma.es/atom/" "Mozilla/5.0 (X11; Linux x86_64; rv:123.0) Gecko/20100101 Firefox/123.0"
192.168.93.1 - - [08/Apr/2024:17:04:26 +0200] "GET /atom/ HTTP/1.1" 504 247 "http://gestion.rivero.uma.es/atom/" "Mozilla/5.0 (X11; Linux x86_64; rv:123.0) Gecko/20100101 Firefox/123.0"

192.168.93.1 - - [08/Apr/2024:17:05:30 +0200] "GET /atom/ HTTP/1.1" 504 247 "http://gestion.rivero.uma.es/atom/" "Mozilla/5.0 (X11; Linux x86_64; rv:123.0) Gecko/20100101 Firefox/123.0"

192.168.93.1 - - [08/Apr/2024:17:06:34 +0200] "GET /atom/ HTTP/1.1" 200 27659 "http://gestion.rivero.uma.es/atom/" "Mozilla/5.0 (X11; Linux x86_64; rv:123.0) Gecko/20100101 Firefox/123.0"

[Dan Gillean]

Hola Mercedes, 

I have asked our team if they have any suggestions for this thread, and unfortunately, there is not much advice we can offer for a complex issue like this on non-standard installations. Given that these 4 installations are otherwise identical but only 2 of them are experiencing issues, it does seem to be deployment related. One developer suggests that you review the routing configuration. I would further suggest double-checking all the configuration blocks you have created, particularly for Apache, as well as your DNS records configuration. 

Otherwise, this is a bit beyond the type of support we can offer via the forum - sorry, and good luck!

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/159b7bf7-16e1-46f8-9946-ef6a4d5bcf31n%40googlegroups.com.

[Mercedes Jiménez Bolívar]

¡Gracias, Dan!, cuando lo resolvamos, te lo contaremos.

[Paulo Partichelli]

Hi,

I'm experiencing the same issue reported by Mercedes.

My installation is standard and followed all the guidelines from https://www.accesstomemory.org/pt-br/docs/2.8/admin-manual/installation/ubuntu/#installation-ubuntu

With the default settings, when logging in with an admin user, after 60s it returns "504 Gateway Time-out" and logs the error below:

2024/04/25 14:49:23 [error] 54437#54437: *44 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 10.99.99.99, server: _, request: "GET /index.php/ HTTP/1.1", upstream: "fastcgi://unix:/run/php7.4-fpm.atom.sock", host: "server", referrer: "http://server/index.php/"

Despite the error, the login is successful. Pressing "enter" returns the page with the admin user logged in.

To avoid receiving the 504 error, I included the following parameters in /etc/nginx/nginx.conf:

       fastcgi_connect_timeout 360s;
        fastcgi_send_timeout 360s;
        fastcgi_read_timeout 360s;

After this configuration, I no longer receive a 504 error, but the login time for admin users is exactly 130s. For regular users, the login is immediate.

[Dan Gillean]

Hi Paulo, 

So far, our developers don't have any suggestions for this, and we have not been able to consistently reproduce the issue in local test installations. 

I have asked our support team if they have seen similar reports for client sites - they told me that the only thing similar they had seen recently was a lot of bot activity causing site slowdowns. This could be seen by checking the Nginx access logs - here is how our team was querying them via the command-line: 

• cat /var/log/nginx/access.log | awk -F\" '{ print $6 }' | sort | uniq -c | sort -rn | head -n 20 ; echo " " ; uptime ; echo -n "php-fpm processes " ; ps -elf|egrep fp[m] | wc -l
  

You can try adding a robots.txt file if this is in fact the case - see for example: 

• https://www.robotstxt.org/
  
• https://moz.com/learn/seo/robotstxt
  

Of course, bad bots will not respect the ROBOTS directives - in which case, you could also configure Nginx to block specific bots and/or IPs as needed. Here is a list of bots we now always block via Nginx configuration, based on them previously crashing client sites with too many requests: 

• https://github.com/artefactual-labs/ansible-nginx/blob/master/defaults/main/bot-lists.yml#L2-L43
  

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/59e9ed8c-5d42-4fe9-8ade-6b9a73bc4695n%40googlegroups.com.

[Mercedes Jiménez Bolívar]

Hello dan. Hello Paulo.
We have discovered why the problem occurs only on some machines and not on others. It only happens when in "Global settings" you select "yes" in "Check for updates"
We checked the network traffic and it put us on the trail of what was happening.
I hope you find it useful.
Cheers.
Mercedes

[Dan Gillean]

Hi Mercedes, 

Very helpful! Thank you for figuring this out and sharing what you discovered. I have informed the Maintainers - hopefully this will help them to reproduce the issue and address it in a future release. 

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/fb4ca3af-c251-47c2-911e-9c483996c245n%40googlegroups.com.

[Paulo Partichelli]

Hi Mercedes, 
Thank you very much for discovering the solution. It worked perfectly on my setup.

Cheers!