mod_fcgid: read data timeout errors

Solution 1:

These errors mean, that the scripts were running longer than 31 seconds and thus they were terminated, as your fcgid.conf says so. The standard timeout is 40 seconds btw.

You can easily check this behaviour by writing a test.php:

<?php sleep(32); ?>

This should give you an error 500 and put this error in your logs.

You have two possibilities to solve this:

1. Re-Make your index.php (or the application behind) and solve potential loop-issues (where the script runs forever and gets terminated after 31 seconds).

2. Set the timeouts higher. This has to be done for every vhost (don't forget SSL!), as this setting gets changed every time another vhost loads and will remain until the spawned process dies.
   Easiest way would be to edit /etc/apache2/mods-available/fcgid.conf. This is what we are using:

   IdleTimeout 3600
ProcessLifeTime 7200
IPCConnectTimeout 8
IPCCommTimeout 600
BusyTimeout 300

Edit: Oh, the second error is related to overly long query strings in URLs. To allow longer query strings, also edit fcgid.conf and insert

MaxRequestLen 15728640

Don't forget to restart apache to kill all running processes, so they get the new configs.

Solution 2:

mysqldump by default will write lock the database while it runs so the data isn't altered during the backup, which can cause corruption. Drupal writes to the database on every request, so requests will hang while mysqldump is running, and eventually timeout.

If you're using InnoDB (or can convert to it), then you can use Percona XtraBackup to do hot backups. Short of that, don't pipe mysqldump to tar or gzip; dump the .sql file and then run tar/gzip on it after mysqldump has completed (and released the lock).

Also be aware that in certain versions of fcgid, there's a bug that causes it to only apply settings in VirtualHost blocks, and to apply those in the last-read block globally.