Any other ideas, tests, or debugging I could try?
Is there a way to check rather the backuppc daemon is listening on the
right ports? Is there a way to debug the FDread variable and see if vec
is correctly adding up all the input sources?
Bruce wrote:
(sending again.. to include the mailing
A Buffalo WZR-HP-G300HN is a Wireless Router/Access Point.
OpenWRT is a version of Linux you can install on many wireless routers.
This thread
Hi, Bruce
My point is that you still don't give me anything to work on
That strace don't mean a thing to me
The other thread didn't add nothing
And, as far as I know, the backuppc server is running on an Access point...
I only know (besides the strace) the backup server hangs (or not), and
Hmmn, Alright. I'll try to add more details. Sorry I wasn't more clear
previously. I had thought I was responding to that thread on the forum
and so left out some details that I felt was already clear in the
forum. But this being put here on the mailing list, I can see how it
seems out of
Hi
I'm really off my league, here
I did a strace on my backuppc 3.0.0 on ubuntu 8.04 (and got Got reply: ok)
$ strace ./BackupPC_serverMesg status 2 temp.txt
But I get nothing like your trace
$ cat temp.txt |grep connect
connect(3, {sa_family=AF_FILE, path=/var/run/nscd/socket}, 110) = -1
ENOENT
Yeah, it may be a good idea for me to try a different version! I'll do
that today.
Les Mikesell had been helping with the last guy maybe once he gets his
gmail account fixed he might have some ideas :)
The strace you show'd me looks about right. You are connected via
sockets so it is
Bruce,
BackupPC_serverMesg status info
The command just hangs. The strace information I provided shows that
it's hanging when trying to read input from the backuppc daemon.
By default the BackupPC programs use a unix-domain socket to
communicate with the BackupPC server. Perhaps the
(sending again.. to include the mailing list)
Craig, thanks for the response!
I have already tested with unix-domain sockets and TCP. I disabled the
sockets when testing the TCP connection in a method similar to what
you've posted.
I get the same results either way.
Craig Barratt wrote:
WTF is a OpenWRT installed on a Buffalo WZR-HP-G300HN?
What are you trying that doesn't work?
If you wish to loose time, try
http://en.wikipedia.org/wiki/Endianness#Big-endian
Regards
Luis
On Fri, Apr 9, 2010 at 9:52 PM, tdhi backuppc-fo...@backupcentral.comwrote:
Closer inspection..
Closer inspection..
BackupPC does finally rest at ..
select(my $rout = $FDread, undef, $ein, $timeout);
and doing some googling I found..
https://dev.openwrt.org/ticket/6900
Where someone is talking about a bug in the select implementation on ar7xx
platforms (same as used by my router).
I know this thread is a bit old.. But I'm having the exact some problem.
I have OpenWRT installed on a Buffalo WZR-HP-G300HN.
This unit has 32m flash, 64m ram, and a 400mhz cpu.
I have already tried everything that has been mentioned in this thread. I have
the exact same problem.
strace
Christoph wrote:
Dear Craig,
It turns out the code always tries the unix
domain socket first.
I used the bogus name for the sockFile method, hence:
my $sockFile = $bpc-{LogDir}/BackupPC.sockNot;
Now BackupPC obviously uses tcp, because after launching the
BackupPC_serverMesg
Craig
Wow, the author himself, what an honour!
It's more likely that TCP sockets work.
Try setting $Conf{ServerHost}, $Conf{ServerPort} and
$Conf{ServerMesgSecret}. BackupPC_serverMesg should
use the TCP port instead of the unix-domain socket.
I set:
$Conf{ServerHost} = 'nslu2';
Dear Craig,
It turns out the code always tries the unix
domain socket first.
I used the bogus name for the sockFile method, hence:
my $sockFile = $bpc-{LogDir}/BackupPC.sockNot;
Now BackupPC obviously uses tcp, because after launching the
BackupPC_serverMesg command, netstat shows:
So it seems that the problem is the same with the tcp connection as with
the unix socket.
Do you have any further idea what the problem could be?
Does anybody know why the read() system call might hang?
Christoph
I'm speculating again, but I can't help thinking that it might be RAM
Christoph,
So it seems that the problem is the same with the tcp connection as with the
unix socket.
Do you have any further idea what the problem could be?
Does anybody know why the read() system call might hang?
Most likely the BackupPC server doesn't see the first message
from
I'm speculating again, but I can't help thinking that it might be RAM
related... Before launching any BackupPC processes, how much RAM is free?
After a reboot I got the following values:
Before launching any BackupPC process:
total used free shared
Hello Craig,
Most likely the BackupPC server doesn't see the first message
from BackupPC_serverMesg.
Is there a possibility to verify that?
I suspect the problem is that perl has a buggy select() or some
other related function or buffering problem on your platform.
Perhaps you could google
Am Dienstag, 25. August 2009 18:30:16 schrieb Michael Stowe:
I installed BackupPC on an NSLU2 more or less according to
http://www.tedcarnahan.com/2009/07/09/installing-backuppc-on-openwrt/
I find this gloriously insane, and I'm actually rather impressed it works
at all.
That's me:
'free' shows:
total used free shared buffers
Mem:3041222128 82840 2428
Swap: 500508 1020 499488
Total: 53092023148 507772
After launching BackupPC_serverMesg it
'top' shows - after starting the Backup-daemon - about 25% %MEM and 0%
%CPU
consumption and about 15% %MEM and 0% %CPU consumption for the second
process.
The BackupPC_serverMesg takes another ~24% %MEM. Do you think that lack of
RAM
might in the end be the true problem? But then - why
On 8/25/09, Michael Stowe mst...@chicago.us.mensa.org wrote:
'top' shows - after starting the Backup-daemon - about 25% %MEM and 0%
%CPU
consumption and about 15% %MEM and 0% %CPU consumption for the second
process.
The BackupPC_serverMesg takes another ~24% %MEM. Do you think that lack of
If you can run vmstat, it will show swap activity. With top, it will
show up as a high percentage on %wa (wait). Or you can cat
/proc/vmstat to get the raw numbers, wait a few seconds, do it again,
and figure out the delta for pswpin and pswpout.
I don't have the vmstat command on the
If the CPU is doing nothing, you've effectively ruled out swap.
Yeah, that's great!
Looking at the code, it's hanging when it's trying to retrieve the MD5
hash seed from {LogDir}/BackupPC.sock (I think I'm reading that correctly)
so you'll next want to check if that's being created and is
Yes, that means you're not swapping. :-)
Jim
On 8/25/09, Christoph ch...@gmx.at wrote:
If you can run vmstat, it will show swap activity. With top, it will
show up as a high percentage on %wa (wait). Or you can cat
/proc/vmstat to get the raw numbers, wait a few seconds, do it again,
and
Christoph wrote:
If you can run vmstat, it will show swap activity. With top, it will
show up as a high percentage on %wa (wait). Or you can cat
/proc/vmstat to get the raw numbers, wait a few seconds, do it again,
and figure out the delta for pswpin and pswpout.
I don't have the vmstat
Christoph wrote:
Not sure, this is REALLY lean (as you know) -- I wouldn't be entirely
surprised if a *lot* of swapping is going on, and combining that with a
slow CPU, it may take a very, very long time for some operations to
complete.
Of course, but even after several hours I did not get
Christoph,
It's possible unix-domain sockets don't work correctly on
your system. BackupPC_serverMesg is blocked waiting for
a reply from the BackupPC server.
It's more likely that TCP sockets work.
Try setting $Conf{ServerHost}, $Conf{ServerPort} and
$Conf{ServerMesgSecret}.
28 matches
Mail list logo
