Wordpress BackupBuddy and LiteSpeed

[craigles]

Hi There,

We currently run LS on a number of our servers, but we are running into an issue with BackupBuddy (A wordpress backup addon) and LS.

It runs the backup just fine, but when transmitting the backup to AWS it seems to time out and doesn't complete.

I turned on debugging in LS to see what is going on and I'm getting this:

2012-10-02 08:12:56.028 [DEBUG] [APVH_j1creati_Suphp:] kill pid 542253 associated with ProcInfo
2012-10-02 08:12:56.028 [DEBUG] [APVH_j1creati_Suphp:] Max idle time reached, stop external application.
2012-10-02 08:12:56.028 [NOTICE] [APVH_j1creati_Suphp:] stop worker processes
2012-10-02 08:12:57.006 [INFO] Pid: 542253 associated with [APVH_j1creati_Suphp:]
2012-10-02 08:12:57.006 [INFO] ProcInfo Pid: -1, socket: /tmp/lshttpd/APVH_j1creative.com_Suphp.sock.862
2012-10-02 08:12:57.006 [INFO] [APVH_j1creati_Suphp:] pid list size: 0, pid stop list size: 0

So I tinkered with the settings in LS a little bit and got further, but I'm not necessarily happy with the settings i'm using now.

Configuration -> External App -> lsphp5 :

Connection Keepalive Timeout = -1
Max Idle Time = 300

With those settings the script seems to run and complete without issue, anything else and it stops and doesn't complete.

Can somebody tell me if those settings are acceptable on a busy shared hosting server or if there is some other way of setting an exception for this virtual hosting account?

Cheers,
Craig

 

[webizen]

You should increase Connection Timeout instead of Max Idle Time.

http://www.litespeedtech.com/docs/webserver/config/tuning/#connTimeout

 

[craigles]

Have tried to increase the Connection Timeout - it's now set to 300 seconds and it still is happening.

2012-10-02 14:06:37.096 [INFO] [APVH_j1creati_Suphp:] add child process pid: 633368, procinfo: 0x35fc520
2012-10-02 14:07:17.072 [DEBUG] [APVH_j1creati_Suphp:] kill pid 633368 associated with ProcInfo
2012-10-02 14:07:17.072 [DEBUG] [APVH_j1creati_Suphp:] Max idle time reached, stop external application.
2012-10-02 14:07:17.072 [NOTICE] [APVH_j1creati_Suphp:] stop worker processes

 

[webizen]

try below in lsphp5 external app

Max Idle Time = -1

 

[craigles]

Thanks for the reply

Unfortunately doing that has done nothing to help the situation.

2012-10-03 13:13:21.516 [INFO] Pid: 897682 associated with [APVH_j1creati_Suphp:]
2012-10-03 13:13:21.516 [INFO] ProcInfo Pid: 897682, socket: /tmp/lshttpd/APVH_j1creative.com_Suphp.sock
2012-10-03 13:13:21.516 [INFO] [APVH_j1creati_Suphp:] pid list size: 1, pid stop list size: 0
2012-10-03 13:13:29.033 [DEBUG] [APVH_j1creati_Suphp:] kill pid 897715 associated with ProcInfo
2012-10-03 13:13:29.033 [DEBUG] [APVH_j1creati_Suphp:] Max idle time reached, stop external application.
2012-10-03 13:13:29.033 [NOTICE] [APVH_j1creati_Suphp:] stop worker processes

 

[webizen]

...
2012-10-03 13:13:29.033 [DEBUG] [APVH_j1creati_Suphp:] kill pid 897715 associated with ProcInfo
2012-10-03 13:13:29.033 [DEBUG] [APVH_j1creati_Suphp:] Max idle time reached, stop external application.
2012-10-03 13:13:29.033 [NOTICE] [APVH_j1creati_Suphp:] stop worker processes

weird. max idle time set to '-1' means no idle time limit and server will not kill the external app. make sure the setting is applied and lsws is restarted to pick it up.

 

[craigles]

OK - I tried downgrading to 4.1.12 and 4.1.11 and the behavior is the same through all versions.

If -1 is specified in the max idle time box the system is just ignoring it, however if you specify a value such as 300 it happily accepts that value.

Any other ideas, the customer is going a bit nuts about this - lol.

 

[webizen]

you can also try 0 for max idle time. if still problem, pm your server temp access for further look

 

[craigles]

Tried setting the max idle time to zero, but it didn't make any difference from what I could see.

I did however install 4.2 and set it to suEXEC PHP Daemon mode and that worked perfect and let backupbuddy complete the send without it stopping and being killed, but there is another issue with 4.2 and the suEXEC PHP Daemon mode which is preventing us from using it.

 

[Jesse]

Webizen, do you have any other ideas on how we can diagnose or rectify this issue under a 4.1.x environment?

Or alternatively a solution to the SuExec issue outlined in http://www.litespeedtech.com/support/forum/showthread.php?t=6299 so this issue can be resolved through deployment of 4.2?

 

[webizen]

...
Or alternatively a solution to the SuExec issue outlined in http://www.litespeedtech.com/support/forum/showthread.php?t=6299 so this issue can be resolved through deployment of 4.2?

We are currently working on a solution (code change) to resolve this (php.ini override in suEXEC daemon mode).

 

[j1creative]

We are currently working on a solution (code change) to resolve this (php.ini override in suEXEC daemon mode).

Hi, I am the client that they were having this issue with.

I was hoping you would be able to give me an ETA on this at all? I have just completed 2 websites for a rather large client that I would like to backup every week if possible.

It seems to have been dragged out to a couple of months to get this working on my hosting environment...

Any help that you could give Craig, Jesse or I would be great.

Thanks so much.

 

[webizen]

Tried setting the max idle time to zero, but it didn't make any difference from what I could see.

I did however install 4.2 and set it to suEXEC PHP Daemon mode and that worked perfect and let backupbuddy complete the send without it stopping and being killed, but there is another issue with 4.2 and the suEXEC PHP Daemon mode which is preventing us from using it.

When max idle set to -1, it will be overridden with 30 seconds (per developer). For the example shown in pm, after 36 seconds, ext app process is removed by parent. However, leave more idle process running will eat up your system resources which is a bad. Therefore, that "Max idle time reached, stop external application." message isn't an indication of problem. It just means these vhosts are not that busy. On the other hand, if you do _not_ care the resource issue, you can leave max idle time long enough to see if message show up less frequently.

 

[j1creative]

I'm not really sure what this means, but hopefully Jesse or Craig will.

 

[webizen]

We are currently working on a solution (code change) to resolve this (php.ini override in suEXEC daemon mode).

This is in 4.2.1 (beta). Due to PHP internal handling, lsphp5 will turn off suEXEC daemon mode on custom php.ini.

 

[kirkm]

Hi,
I also have the same issue with BackupBuddy and LiteSpeed.
Transfer of the backups to Amazon S3 do not complete.
The only workaround for me is to switch back to Apache, manually send the backups, then switch back to LiteSpeed.

If you could update this thread with any progress on this issue, that would be great.
Thanks,
Kirk.

 

[webizen]

I am taking you need to php run as long as it can without timeout.

http://www.litespeedtech.com/support/wiki/doku.php?id=litespeed_wiki:php_run_without_timeout

 

[kirkm]

Thanks for your response.

I tried increasing the times on the first three options described on the link you provided.
1) LiteSpeed connection timeout override - Increased to 240
2) PHP execution time in php.ini - Increased to 120
3) LSAPI_MAX_PROCESS_TIME - Couldn't find this option in Litespeed v4.1.13, so I tried increasing lsphp5 Max Idle Time to 60.

Unfortunately, none of these timer increases worked for me.

Do you have any other suggestions that I could try?

 

[mistwang]

Please try 4.2.1

/usr/local/lsws/admin/misc/lsup.sh -f -v 4.2.1

 

[kirkm]

Hi,
Just letting you know that the update to LiteSpeed 4.2.1 appears to have fixed my problems with transferring BackupBuddy backup files to Amazon S3.

Currently the backups are only around 100MB. Maybe timeouts could be an issue with larger files, but the first few transfers I tried are working ok (with standard configuration).

Thanks for your help with this issue.
Kirk.