Plesk users may notice the error “AH01075: Error dispatching request to” in the domain’s error logs along with a “504 Gateway Time-out” or “503 Service Temporarily Unavailable” error on the website.

As part of our Server Management Services, we assist our customers with several Plesk queries.

Let us today discuss both of these cases differently.

Plesk “AH01075: Error dispatching request to”

Moving ahead, let us see how our Support Techs go about these errors.

503 Service Temporarily Unavailable on Plesk

Symptoms of this error include:

• The /var/www/vhosts/example.com/logs/error_log file shows:

[proxy_fcgi:error] [pid 350:tid 139649016084224] (104)Connection reset by peer: [client 203.0.113.2:58642] AH01075: Error dispatching request to :, referer: http://example.com/wordpress/wp-admin/upload.php

• `dmesg` command output shows:

[4289853.349670] php-cgi[49424]: segfault at 30 ip 00007fc662113088 sp 00007fc630ad3d10 error 4
[4289853.349672] in libMagickCore.so.5.0.0[7fc661f8e000+237000]

An ImageMagick library bug can cause this error.

In order to fix this, we disable the Imagick PHP module for PHP handler for the website:

1. To do so, we log in to Plesk
2. Browse to Tools & Settings > PHP Settings
3. Then click on the PHP handler that is set for the domain, e.g. PHP 5.6:
4. To disable the extension, we Uncheck the Imagick checkbox:
5. Later, we ensure that no sites are using this module.

Make note that these settings are common to the 5.6.36 CGI applications, 5.6.36 FastCGI applications. The settings apply to all websites that use these handlers.

504 Gateway Time-out on website

Symptoms of this error include:

• Website example.com is not accessible. We come across the below error in a browser:

504 Gateway Time-out

• In the domain error log file, Domains > example.com > Logs, we see the error:

[proxy_fcgi:error] [pid 42290:tid 140458047010560] (70007)The timeout specified has expired: [client 203.0.113.2:54693] AH01075: Error dispatching request to :, referer: http://example.com/gallery

• In the Plesk > Domains > example.com > PHP Settings it shows the website uses a “FastCGI application” (not an “FPM application”) PHP handler.

The cause of this error can be the execution PHP code of the website takes longer than the specified timeout.

To fix the issue, we increase the timeout. We can increase the FastCGI limits for an affected domain only or on a server-wide level.

Increase the FastCGI limits for a single domain:

1. Log into Plesk
2. Then, go to Domains > example.com > Apache & Nginx Settings.
3. We add the following lines to the text boxes Additional directives for HTTP and Additional directives for HTTPS:

   FcgidIdleTimeout 1200
   FcgidProcessLifeTime 1200
   FcgidConnectTimeout 1200
   FcgidIOTimeout 1200
   Timeout 1200
   ProxyTimeout 1200

   However, if the website still shows “504 Gateway Timeout” we increase timeouts to higher values.

4. Finally, we click OK to apply the changes.

Increase the FastCGI limits server-wide:

1. We connect to the Plesk server via SSH as the root user.
2. Then we open the FastCGI configuration file fcgid.conf in a text editor. The location of the file depends on the operating system:
   (a) for CentOS/RHEL/CloudLinux distributions:

    

   /etc/httpd/conf.d/fcgid.conf

   (b) for Debian/Ubuntu distributions:

   /etc/apache2/mods-enabled/fcgid.conf

3. Eventually, we increase FastCGI timeout limits:

   FcgidIdleTimeout 1200
   FcgidProcessLifeTime 1200
   FcgidConnectTimeout 1200
   FcgidIOTimeout 1200

4. If we use FPM PHP handler to create /etc/httpd/conf.modules.d/00-proxy_timeout.conf then we add the following lines into it:

   Timeout 1200
   ProxyTimeout 1200

5. Then we test configuration with “apachectl configtest” command. The output will be similar to:

   # apachectl configtest
   Syntax OK

6. Then we restart Apache:
   (a) for CentOS/RHEL-based operating systems:

    

   # service httpd restart

   (b) for Debian/Ubuntu-based operating systems:

   # service apache2 restart

[Need help with the fix? We’d be happy to assist]

Conclusion

In short, we saw how our Support Techs fix the Plesk error.