cannot install 2.5.3: 504 gateway timeout

[mpw...@ualberta.ca]

PREVIOUS THREAD: https://groups.google.com/forum/#!topic/ica-atom-users/fv964LjcFZs

The solution in that thread (manually edit the URL to go on to the next step) did NOT work on one server.

Ubuntu 16.04

Nginx 1.10.3

PHP 7.0.33

MySQL 5.7

I get to the search configure page as usual, then the 504 gateway timeout, and the URL is:

http://<host>/index.php/sfInstallPlugin/loadData

Then I manually change the URL to:

http://<host>/index.php/sfInstallPlugin/configureSite

...and I just get another 504 gateway timeout.

Nothing is written to the nginx logs during this.

Any thoughts? 

[Dan Gillean]

Hi Michael, 

When trying this, did you first wait at least 20-30 seconds after the first 504 timeout message, to allow the original task time to complete, before changing the URL to /configureSite? This is per this part of the thread in the forum post that Matthew shared with you. 

Note there is also a second suggestion (which also requires waiting a bit after the initial 504) - just going to your base URL. See here in that thread. 

If that still didn't work, have you tried the B) solution listed in the thread that Matthew linked - modifying the Nginx fastcgi timeout value?

We are continuing to investigate this issue using ticket #13051 and are working on a more permanent solution for the 2.6 release. 

Regards, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

--
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/e29788dd-c1a1-429d-b0f5-2c282d1c63ce%40googlegroups.com.

[Michael Ward]

Thanks Dan, I'll try that. Perhaps I am too impatient.

You received this message because you are subscribed to a topic in the Google Groups "AtoM Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ica-atom-users/4tjsJglBxPw/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAC1FhZJEBNrX90AQxXim_MLida-ouqE_70VQ9CqZk1ZfU73zzQ%40mail.gmail.com.

--

Michael Ward

Arts Resource Centre (ARC)

450 Arts, University of Alberta, Edmonton, Alberta, T6G 2E6

780-492-5278

[Michael Ward]

Hi Dan,

Just FYI, I came up with a different strategy.

Do a mysqldump every minute or so; when it stops getting bigger (around 580Kb), it's done and you can move on to the next step (/configureSite).

[Dan Gillean]

Interesting! Thanks for sharing what worked for you, Michael! Hopefully it might help others as well, until we add a more permanent solution! 

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/CAAUb%2B1rNUToUGft1rPZ7bBx9xYCGsrJmAiHejC3Mg-uSXmYC_g%40mail.gmail.com.

[Michael Ward]

You are most welcome.

ANOTHER way to avoid the timeout - forgot to mention this: increase all the execution times to ~10 min.

In /etc/php/7.2/fpm/pool.d/atom.conf:

php_admin_value[max_execution_time] = 600

In /etc/php/7.2/fpm/php.ini:

max_execution_time = 600
max_input_time = 600

In /etc/nginx/nginx.conf:

http {
     fastcgi_read_timeout 600;
     proxy_read_timeout 600;
...

You'll want to change them back to the defaults after.

One of my servers took 8 MINUTES to populate the dbase. And this is not old hardware, 6 cores, 8G RAM.

Why does it take so long?

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZLLAAVeVO07Qea3HzGEVhEg9j9ic3tN3HJLjQSnrACB9Q%40mail.gmail.com.

[Dan Gillean]

Hi Michael, 

I'm not sure of the exact reason for such a long delay - typically it is Elasticsearch that requires a lot of time and memory to first install, not the database. However, I also suspect that part of the issue is the Symfony 1.x framework managing the database via its Propel ORM, and the web installer. 

For the 2.6 release we are investigating the possibility of doing away with the web installer - or at least moving the database and ES configuration to the command-line to avoid these kind of issues. Users installing AtoM are already in the command-line during the installation process, and if it is the web installer adding delays and timeouts, it is just as easy for a system administrator to add the database credentials, search index name, and other configuration details via the CLI. 

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/CAAUb%2B1q%2B5k6WShiepJRsQzRHwaaD8i%2BABJ-kWHac%3DCjvedNwEg%40mail.gmail.com.

[Patrick Goetz]

On Friday, January 17, 2020 at 10:03:03 AM UTC-6, Dan Gillean wrote:

For the 2.6 release we are investigating the possibility of doing away with the web installer - or at least moving the database and ES configuration to the command-line to avoid these kind of issues. Users installing AtoM are already in the command-line during the installation process, and if it is the web installer adding delays and timeouts, it is just as easy for a system administrator to add the database credentials, search index name, and other configuration details via the CLI.

Additionally, the web installer doesn't play nicely when AtoM is installed in a container accessed remotely through an HTTP proxy: The only way i've been able to get it to work is working directly from the console of the container host, which isn't generally going to be an option.  Once the installation is done, AtoM becomes remotely accessible (so it's not the access configuration).