Wordpress BackupBuddy and LiteSpeed

M

mistwang

LiteSpeed Staff
#21
#21
It is recommended to update 4.2.1 installation to the latest build, either force reinstall from web console, or from command line, do

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

With the latest build, you may need to explicitly set "Auto Start" to "Through CGI daemon" for lsphp5 external app to make BackupBuddy work properly.
 
K

kirkm

Member
#22
#22
Hi,
After more testing, transfers are still not working reliably. Seems to work maybe once out of every ten attempts.

I have updated to v4.2.1 and changed the Auto Start option to "Through CGI daemon" and that hasn't helped.

It might be a problem on the server I am using at VPS.net, but when I switch back to Apache, transfers work fine, which points to a LiteSpeed issue.

FTP transfers with BackupBuddy seemed to be more reliable, but transfers to Amazon S3 or Rackspace Files... are always unreliable.

Do you have any other suggestions that I could try?

Thanks,
Kirk.
 
M

mistwang

LiteSpeed Staff
#23
#23
I think should strace the lsphp5 doing the backup to find out exactly what happened.

strace -tt -T -p <pid_of_lsphp5_doing_backup>

whether it is killed by LSWS, or due to PHP internal limit.
 
D

dwalsh0

New Member
#26
#26
Does anyone have any more information on this problem?

We're still trying to find the root cause.

I've ran a strace on the process:

Process 166598 attached - interrupt to quit
10:13:26.697084 select(5, [4], NULL, NULL, {0, 415000}) = 0 (Timeout) <0.419247>
10:13:27.116602 getppid() = 166110 <0.000053>
10:13:27.116752 select(5, [4], NULL, NULL, {1, 0}) = 0 (Timeout) <1.000359>
10:13:28.117272 getppid() = 166110 <0.000053>
10:13:28.117420 select(5, [4], NULL, NULL, {1, 0}) = 0 (Timeout) <1.000788>
10:13:29.118418 getppid() = 166110 <0.000096>
10:13:29.118635 select(5, [4], NULL, NULL, {1, 0}) = 0 (Timeout) <1.000378>
10:13:30.119164 getppid() = 166110 <0.000052>
10:13:30.119306 select(5, [4], NULL, NULL, {1, 0}) = 0 (Timeout) <0.999900>
10:13:31.119526 munmap(0x2af8d2cd5000, 1126176) = 0 <0.000085>
10:13:31.119778 munmap(0x2af8d2a46000, 2681400) = 0 <0.000057>
10:13:31.119936 munmap(0x2af8d282f000, 2189400) = 0 <0.000051>
10:13:31.120063 munmap(0x2af8d25e7000, 2391008) = 0 <0.000047>
10:13:31.120236 munmap(0x2af8d0954000, 2133160) = 0 <0.000025>
10:13:31.120353 munmap(0x2af8d0b5d000, 3059536) = 0 <0.000042>
10:13:31.120478 munmap(0x2af8d0e48000, 9292800) = 0 <0.000067>
10:13:31.120629 munmap(0x2af8d1725000, 2152872) = 0 <0.000022>
10:13:31.120735 munmap(0x2af8d1933000, 2619808) = 0 <0.000033>
10:13:31.120850 munmap(0x2af8d1bb3000, 4057800) = 0 <0.000051>
10:13:31.120984 munmap(0x2af8d1f92000, 2273208) = 0 <0.000023>
10:13:31.121089 munmap(0x2af8d21bd000, 2114984) = 0 <0.000021>
10:13:31.121235 munmap(0x2af8d0747000, 2149128) = 0 <0.000023>
10:13:31.121367 munmap(0x2af8d0544000, 2107704) = 0 <0.000021>
10:13:31.121499 munmap(0x2af8d033d000, 2125488) = 0 <0.000021>
10:13:31.121649 munmap(0x2af8d00eb000, 2432000) = 0 <0.000034>
10:13:31.121799 munmap(0x2af8cfed3000, 2194408) = 0 <0.000026>
10:13:31.122464 fcntl(3, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0 <0.000017>
10:13:31.122593 fcntl(3, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0 <0.000012>
10:13:31.166471 shmdt(0x2af8d2de8000) = 0 <0.007365>
10:13:31.174114 shmctl(1468301324, IPC_RMID, 0) = -1 EINVAL (Invalid argument) <0.000013>
10:13:31.174288 close(3) = 0 <0.000013>
10:13:31.174386 unlink("/tmp/session_mm_litespeed531.sem") = 0 <0.000049>
10:13:31.174952 brk(0x1642f000) = 0x1642f000 <0.001085>
10:13:31.176142 brk(0x1617d000) = 0x1617d000 <0.000426>
10:13:31.177453 munmap(0x2af8cfcd8000, 2075016) = 0 <0.000062>
10:13:31.177840 brk(0x15280000) = 0x15280000 <0.002537>
10:13:31.180564 munmap(0x2af8cfc89000, 323584) = 0 <0.000022>
10:13:31.181177 exit_group(0) = ?
Process 166598 detached
 
W

webizen

Well-Known Member
#31
#31
dwalsh0 said:
...
I've ran a strace on the process:

Process 166598 attached - interrupt to quit
10:13:26.697084 select(5, [4], NULL, NULL, {0, 415000}) = 0 (Timeout) <0.419247>
10:13:27.116602 getppid() = 166110 <0.000053>
10:13:27.116752 select(5, [4], NULL, NULL, {1, 0}) = 0 (Timeout) <1.000359>
10:13:28.117272 getppid() = 166110 <0.000053>
10:13:28.117420 select(5, [4], NULL, NULL, {1, 0}) = 0 (Timeout) <1.000788>
10:13:29.118418 getppid() = 166110 <0.000096>
10:13:29.118635 select(5, [4], NULL, NULL, {1, 0}) = 0 (Timeout) <1.000378>
10:13:30.119164 getppid() = 166110 <0.000052>
10:13:30.119306 select(5, [4], NULL, NULL, {1, 0}) = 0 (Timeout) <0.999900>
10:13:31.119526 munmap(0x2af8d2cd5000, 1126176) = 0 <0.000085>
...
...
...
10:13:31.174952 brk(0x1642f000) = 0x1642f000 <0.001085>
10:13:31.176142 brk(0x1617d000) = 0x1617d000 <0.000426>
10:13:31.177453 munmap(0x2af8cfcd8000, 2075016) = 0 <0.000062>
10:13:31.177840 brk(0x15280000) = 0x15280000 <0.002537>
10:13:31.180564 munmap(0x2af8cfc89000, 323584) = 0 <0.000022>
10:13:31.181177 exit_group(0) = ?
Process 166598 detached
Click to expand...
The strace is on an idle lsphp5 NOT the one handles the upload. So you have to find the right one and strace again.
 
M

MikeDVB

Well-Known Member
#32
#32
We are constantly having people report BackupBuddy does not work with our services, something about there being no loopback.

It works fine with Apache, just not LiteSpeed. It's unfortunate because a lot of our clients choose to use BackupBuddy.
 
M

mistwang

LiteSpeed Staff
#33
#33
That's because BackupBuddy does not wait for background request finish, closed the HTTP connection.
The fix for previous customer is, upgrade to latest 4.2.2, add the following rewrite rule to .htaccess at the root directory of wordpress installation.

RewriteRule ^$ - [E=noabort:1]
 
M

MikeDVB

Well-Known Member
#34
#34
mistwang said:
That's because BackupBuddy does not wait for background request finish, closed the HTTP connection.
The fix for previous customer is, upgrade to latest 4.2.2, add the following rewrite rule to .htaccess at the root directory of wordpress installation.

RewriteRule ^$ - [E=noabort:1]
Click to expand...
We are on 4.2.2 - I will have the client try this.
 
J

Jesse

Member
#36
#36
mistwang said:
may need to change rewrite rule to
Click to expand...
Thank you for this.

Why was the rule to resolve this issue changed without warning? One day it was working and then it appears it was simply pulled... This caused us numerous issues for our clients as a once working solution was failing again.
 
N

NiteWave

Administrator
#37
#37
that may not be the final solution, just an workaround.
we're still working on it --- to identify the root cause and completely fix it.

Can you provide a test case which can 100% reproduce the issue?
I have tried to reproduce the issue on our lab but not succeeded yet.

backup size is about 30M, backup to ithemes's own "BackupBuddy Stash".
use multipart uploads, max 15M every time. but succeeded without any issue.
this is what I thought will trigger the issue, but backup succeeded.

not tested with dropbox, S3 etc.
 
R

remas100

New Member
#38
#38
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.
 
N

NiteWave

Administrator
#39
#39
the new rewrite environ variable E=noabort:1 only available since 4.2.2

so please upgrade to 4.2.2 and try this solution:
<IfModule litespeed>
RewriteRule .* - [E=noabort:1]
</IfModule>
 
N

NiteWave

Administrator
#40
#40
some people reached here from google search, so here's the update after about exact 1 year later:

at present, lsws's version is 4,2,11
to resolve the backupbuddy issue
1. .htaccess in wordpress's home directory:
<IfModule litespeed>
RewriteEngine On
RewriteRule ^wp-cron.php$ - [E=noabort:1]
</IfModule>

this may resolve most of the backupbuddy issue.

2. if backupbuddy still fail in some cases, try to increase
lsws web admin --> Server --> External App --> lsphp5
Max Idle Time: 10
this is the default value in shared hosting environment, increase it to 20/30/60/120/300 etc.

3. in a cloudlinux + litespeed server, when LVE i/o limit is 1024 KB/sec, backupbuddy took very long time to complete, this is not relating to litespeed or apache directly, but the LVE i/o limit on that server. when host change the limit to 0 (no limit), backupbuddy took a few seconds instead of 10+ minutes.

 
You must log in or register to reply here.
Top