• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Searching large mailbox in Horde/roundcube causes "mod_fcgid: read data timeout"

Visnet

Basic Pleskian
This is applies to both Horde and roundcube webmail client software;
Using Plesk 11.5.30 with Horde 5.1.5 or roundcube 0.9.5 on CentOS Linux release 6.5 (Final).
We have seen this behavior occur on multiple servers.

Clients experienced slow to no response after executing a search, which eventually results in a failed to communicate with the server-error in the webmail client.
The Apache server log shows script time-out errors when searching larger mailboxes (i.e. larger than 950 MB), this does not happen on smaller mailboxes.

We have seen errors like the following in the Apache server error log with Horde (personal data like IP-address and domain name are x'ed out):
[Thu Jun 19 14:55:06 2014] [warn] [client xx.xxx.xxx.xxx] mod_fcgid: read data timeout in 45 seconds, referer: http://webmail.xxxxxxx.com/imp/dynamic.php?page=mailbox
[Thu Jun 19 14:55:06 2014] [error] [client xx.xxx.xxx.xxx] Premature end of script headers: ajax.php, referer: http://webmail.xxxxxxx.com/imp/dynamic.php?page=mailbox

and with Roundcube:
[Tue Jun 17 13:02:04 2014] [warn] [client xx.xxx.xxx.xxx] mod_fcgid: read data timeout in 45 seconds, referer: https://webmail.xxxxxxxxxxx.com/?_t...d=19445&_mbox=INBOX&_caps=pdf=0,flash=1,tif=0
[Tue Jun 17 13:02:04 2014] [error] [client xx.xxx.xxx.xxx] Premature end of script headers: index.php, referer: https://webmail.xxxxxxxxxxx.com/?_t...d=19445&_mbox=INBOX&_caps=pdf=0,flash=1,tif=0

Steps to reproduce:
- use a large mailbox (950 MB or higher)
- login to the webmail (Horde or roundcube)
- do a search in the search field on the top right
- the time-out error should appear in the server Apache error log (after at least 45 seconds)

This seems like an inefficiency or bug in the search query that searches the user's mailbox.

Does anyone see this same behavior on their server?

It seems strange that a search query should take more than 45 seconds to execute, so raising the limit would not be a workable solution.
Is there any other way we can prevent this issue and the error messages?
 
Hello,

As the application is running as fastcgi, then the data query is required to be processed within the IO timeout. Raising the limit would be the solution.

Suggestion:
Code:
nano /etc/httpd/conf.d/fcgid.conf

FcgidIdleTimeout 115
FcgidIOTimeout 120

_Zigge
 
Raising the limit would be the solution.

Don't you agree that a search query that takes 45 seconds (or longer) would be totally useless?
I suppose a search query should take a maximum of say 5 seconds, regardless of the size of the mailbox.

Compare this behavior to executing search queries on a large mailbox on popular webmail clients like Gmail or Yahoo Mail, and it makes the Horde/roundcube behavior irrelevant and unusable.
I guess that's not the intention of Horde nor roundcube nor Plesk.
 
Thanks for you advice, of course I appreciate it.

I am aware of the possibilities of changing the configuration values you mentioned to influence the search query time.
However, optimizing this way eventually seems to have too little impact on the search query time.
A search query of more than 45 seconds will a problem for all users searching larger mailboxes, since it fails or simply takes too long to be useful.

I believe the focus should be on optimizing the way the mailboxes are being searched, instead of raising limits for the current search query (which is not optimized).
Maybe create a search index database, show results dynamically directly when found, or whatever other method would be available.

Parallels, can you fix this in a future version of Horde/roundcube?

Or does anyone else have a solution to this issue?
 
Back
Top