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
(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:
> Br
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 un
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 slightl
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
ENO
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, 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 you
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
http://www.backupcentral.com/phpBB2/two-way-mirrors-of-external-mailing-lists-3/backuppc-21/installation-problems-backuppc-servermesg-hangs-100151/#33232
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 wrote:
>
> Closer inspection..
>
> BackupPC does finally "rest" at .
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
> Bac
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 go
> 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 b
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 Ba
> 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 RA
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 s
> 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';
$Co
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}. BackupPC_serverMe
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
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
Yes, that means you're not swapping. :-)
Jim
On 8/25/09, 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
> 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 Ope
> 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
On 8/25/09, Michael Stowe 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
>> RAM
>> might in
> '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 -
> 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 any response - i
> 'free' shows:
> total used free shared buffers
> Mem:3041222128 82840 2428
> Swap: 500508 1020 499488
> Total: 53092023148 507772
>
> After launching BackupPC_serverMes
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:
> Hello,
>
> 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.
> When I launch the server daemon, it starts without any error messages
28 matches
Mail list logo
