• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Forwarded to devs max_execution_time not respected when serving by Nginx and proxy mode is off

Denis Gomes Franco

Regular Pleskian
TITLE:
max_execution_time not respected when serving by Nginx and proxy mode is off
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:
Plesk Obsidian Version 18.0.20
PROBLEM DESCRIPTION:
Looks like the 'max_execution_time' and 'max_input_time' settings are not respected when a domain is running on a pure Nginx set up, eg., PHP is set up to run an FPM application served by Nginx, and the Nginx proxy mode option is off.

I tried using the WXL import option in Wordpress with a large file and Nginx always throws a gateway timeout error after 30 or 60 seconds (not sure which one it is) despite setting 2000 or more as the PHP timeout for that domain.

Switching off Nginx for the domain and serving it via Apache solves the problem.​
STEPS TO REPRODUCE:
1. Open up the PHP settings for a domain.
2. Change 'max_execution_time' and 'max_input_time' to anything above 60 seconds.
3. Run a PHP script that takes longer than 60 seconds to complete.

The Wordpress import function may very well take dozens of minutes to complete if you enable the DOWNLOAD AND IMPORT FILE ATTACHMENTS and the site has lots of media files that will have to be copied from the old server.​
ACTUAL RESULT:
The operation should finish without errors. In case of Wordpress, it should display the results of the import operation.​
EXPECTED RESULT:
Nginx throws a GATEWAY TIMEOUT error.​
ANY ADDITIONAL INFORMATION:
YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:
Confirm bug
 
Of course, max_execution_time won't be respected by Nginx, because it's not related to Nginx at all.
Try setting these Nginx config variables:
fastcgi_connect_timeout
fastcgi_read_timeout
fastcgi_send_timeout

Or make sure your script is sending some data back from time to time to avoid disconnects from Nginx or from user's web browser (which also could occur after some time of remote peer inactivity)
 
Last edited:
Nice...
But then, these options could be included in Plesk's GUI. Rereading my post with your reply in mind, it now looks like the current interface is leading me to believe that these options were not working as intended.
 
Nice...
But then, these options could be included in Plesk's GUI. Rereading my post with your reply in mind, it now looks like the current interface is leading me to believe that these options were not working as intended.

Exactly! It appears like settings and values like 'max_execution_time' or 'max_input_time' are completely rendered out and useless.


Or make sure your script is sending some data back from time to time to avoid disconnects from Nginx or from user's web browser (which also could occur after some time of remote peer inactivity)

You can't possibly be serious or i am understanding you wrong way? So in your example i should beg every wordpress extension developer out there to change their tools which rely on max_execution_time values set in PHP. Like backup plugins archiving large sites etc.?

To me it's logical that if i set 'max_execution_time' to X value, Apache and Nginx should be synced in the background and respect my values. cPanel did it right. It's possible.

Example: Plesk - FPM application served by Apache.
max_execution_time = 60 - i run backup and i get nginx error and timeout after 60 seconds.

I increase max_execution_time in PHP = to 900!! - i get same error after 60 seconds. (yes even if i switch to FPM application served by Nginx)

execution time is not respected (unless i switch off Nginx).

Example 2. cPanel - FPM application served by Apache.
max_execution_time = 60 - i run backup and i get nginx error and timeout after 60 seconds.
I increase max_execution_time in PHP = to 900 - no issues - working as it's supposed to work.

I even intentionally run script and count on my stopwatch. On Cpanel it's respected (900 seconds), on Plesk it's NOT!!
 
Anyone from Plesk to put any light on this? At least something? This can't just be ignored as "user error situation" ? Come on - we periodically have plenty of Wordpress people complaining about plugins returning timeout errors after 60 secs even though values much bigger then 60 ( insanely big in some cases ).

And it doesn't really matter if FPM is served by Apache or NGINX
 
From developer:

The issue is confirmed: PPP-45489
But note that the fix could have a negative effect on other customers, we should think twice before this change.
 
From developer:

The issue is confirmed: PPP-45489
But note that the fix could have a negative effect on other customers, we should think twice before this change.
Thank you Igor. I don't want to force this (i don't believe that i even can do that) so basically let Plesk team decide what's best. I would not want other people have issues. Perhaps some new settings can be added or something. Or something like - Plesk leave this as is but provide us undoubtedly clear article on how can we fix this permanently - if we want.

Anyway i am sure Plesk is up to the task. Just keep us posted or should we monitor changelog?
 
I am getting a 500 error when I activate Apache (turn on proxy mode), therefore I can not run anything higher than 30 max_execution_time and the Media Cleaner plugin keeps crashing on me.

Anyway I can increase max_execution_time without activating Apache (proxy mode)?
 
Back
Top