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/we...g/#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]

Originally Posted by craigles

...
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...ead.php?t=6299 so this issue can be resolved through deployment of 4.2?