On Fri, Sep 20, 2019 at 13:11:08 +, Robert Reilly wrote:
> Nathan, the backup completed successfully with setting the estimate to
> server. Here is the planner log from last nights failed backup.
> https://gist.github.com/rreilly-edr/4f9f7373049124b28fd1da75ffcfe917
Robert, did you ever have
e" processes on the clients during this waiting period. Data
from those processes has to go back to the server via a complicated
chain (simplified, this chain seems to be something like: calcsize ->
sendsize -> amandad -> sshd ---[network to server]--> ssh-auth-
On Fri, Sep 20, 2019 at 13:28:42 +, Robert Reilly wrote:
>
> First one is the failed backup second is the successful backup
>
> https://gist.github.com/rreilly-edr/debff9f0ce3a1759993083b54a966cda
Okay, thanks. I see you posted a link to your amanda.conf earlier in
the thread; can you also
@amanda.org
Subject: Re: amandad defunct on client calcsize/sendsize hung
On Fri, Sep 20, 2019 at 13:11:08 +, Robert Reilly wrote:
> Nathan, the backup completed successfully with setting the estimate to
> server. Here is the planner log from last nights failed backup.
> https://gist.g
On Fri, Sep 20, 2019 at 13:11:08 +, Robert Reilly wrote:
> Nathan, the backup completed successfully with setting the estimate to
> server. Here is the planner log from last nights failed backup.
> https://gist.github.com/rreilly-edr/4f9f7373049124b28fd1da75ffcfe917
Can you post the planner
Stratton Treadway
Sent: Thursday, September 19, 2019 10:06 PM
To: amanda-users@amanda.org
Subject: Re: amandad defunct on client calcsize/sendsize hung
On Wed, Sep 11, 2019 at 17:21:10 +, Robert Reilly wrote:
> not sure what other debug logs make sense to send..
"amdump" in a way is j
PM
To: amanda-users@amanda.org
Subject: Re: amandad defunct on client calcsize/sendsize hung
On Thu, Sep 12, 2019 at 17:48:28 +, Robert Reilly wrote:
> I did a while loop started the backup and I see that noop is also
> defunct but dose get cleaned up
>
> backup8919 8
w
you exactly what the server is sending to the client at the time that
the sendsize step gets hung.
Nathan
Nathan Stratton Treadway - natha...@ontko.com - Mid-At
"noop"
process to remain defunct for a short period of time while the main
amandad process copies the noop process's data back over the network to
the server, but then once that copying has finished the "noop" process
is cleaned up.
Probably the same thing would hap
On Wed, Sep 11, 2019 at 17:21:10 +, Robert Reilly wrote:
> Here is the latest amandad debug file from the client
> https://gist.github.com/rreilly-edr/fcc7660a9393d292bfd1437c7636826a
>
> amdump log from server
> https://gist.github.com/rreilly-edr/cf306ce10c594bc7b9bf5c06a98722b2
>
> not
is defunct must be what is hanging the backup, I
> have not been able to figure out why amandad is going defunct though.
> rob
>
> sshd?amandad?2*[amandad]
>??sendsize?2*[sendsize?calcsize]
>
> root 20206 1322 0 17:18
Robert Reilly writes:
> All, Is there a way to run the backup manually to see whats happening on the
> client outside of running strace on amdump ?
> Rob
Please:
1. clear environment (kill zombies, hung processes, etc)
2. try to backup single host
3. try to backup all hosts EXCEPT amanda
/sendsize hung
KJ, unfortunately the something amandad on the client gets defunct and there
procs do not go away until I kill them. The procs hang ( I think until timeout
) and get an EOF in the log.
The fact that amandad is defunct must be what is hanging the backup, I have not
been able
@amanda.org
Subject: RE: amandad defunct on client calcsize/sendsize hung
KJ, unfortunately the something amandad on the client gets defunct and there
procs do not go away until I kill them. The procs hang ( I think until timeout
) and get an EOF in the log.
The fact that amandad is defunct must
amandad is going defunct though.
rob
sshd───amandad─┬─2*[amandad]
└─sendsize───2*[sendsize───calcsize]
root 20206 1322 0 17:18 ?00:00:00 sshd: backup [priv]
backup 20217 1 0 17:18 ?00:00:00 /lib/systemd/systemd --user
backup 20218 20217 0 17:18
Robert Reilly writes:
> Hi, All I have setup Amanda, it works great for the Amanda server itself but
> fails to backup any clients.
> Server:
> Ubuntu 18.04
> Amanda 3.5.1 ( ubuntu repo pkg )
Whats happening when you try to backup single client?
i.e. amdump clienthost?
does it works?
KJ
--
*Sent:* Wednesday, September 11, 2019 8:31 AM
> *To:* amanda-users@amanda.org
> *Subject:* RE: amandad defunct on client calcsize/sendsize hung
>
>
>
> All,
>
> I also tried this on an 18.04 client wit 3.5.1 amanda client and I get
> the same result defunct process and
> *To:* amanda-users@amanda.org
> *Subject:* amandad defunct on client calcsize/sendsize hung
>
>
>
> Hi, All I have setup Amanda, it works great for the Amanda server itself
> but fails to backup any clients.
>
> Server:
>
> Ubuntu 18.04
@amanda.org
Subject: Re: amandad defunct on client calcsize/sendsize hung
Too bad that it did not help. I still have no idea what the reason for that
problem is.
I assume you are using the packages amanda-server and amanda-client from
Ubuntu's repository. I remember there were several issues
Message-
From: owner-amanda-us...@amanda.org On Behalf
Of Robert Reilly
Sent: Wednesday, September 11, 2019 10:30 AM
To: Jens Berg ; amanda-users@amanda.org
Subject: RE: amandad defunct on client calcsize/sendsize hung
Thanks I will give it a try and report back.
-Original Message
t calcsize/sendsize hung
All,
I also tried this on an 18.04 client wit 3.5.1 amanda client and I get the same
result defunct process and no backup. I am at a loss as what could be causing
this I have spent many hours debugging. Any thoughts ?
From: owner-amanda-us...@amanda.org<mailto:ow
Thanks I will give it a try and report back.
-Original Message-
From: Jens Berg
Sent: Wednesday, September 11, 2019 10:18 AM
To: Robert Reilly ; amanda-users@amanda.org
Subject: Re: amandad defunct on client calcsize/sendsize hung
Hi,
the hanging processes are strange, no idea about
, September 6, 2019 10:55 AM
To: amanda-users@amanda.org
Subject: amandad defunct on client calcsize/sendsize hung
Hi, All I have setup Amanda, it works great for the Amanda server itself but
fails to backup any clients.
Server:
Ubuntu 18.04
Amanda 3.5.1 ( ubuntu repo pkg )
Client
Ubuntu 16.04
?00:00:00 [amandad]
backup 30679 30646 0 11:36 ?00:00:00 /usr/lib/amanda/sendsize
amandad ssh
backup 30680 30646 0 11:36 ?00:00:00 [amandad]
backup 30683 30679 0 11:36 ?00:00:00 /usr/lib/amanda/sendsize
amandad ssh
Amanda.conf
https://gist.github.com
Another server:
a sendsize process hangs and hangs ... and I can't kill it or
amcleanup -k ... any ideas aside from rebooting?
Stefan
that amcheck runs as user amandabackup so it
couldn't read /jag/cnds. But amdump runs (or its client-side daemon runs)
as root so it can read this dir regardless.
So pushing fwd and running amdump, I got errors like this:
planner: ERROR cfile-local: service sendsize: sendsize: Failed to
chdir(/jag
and saw that amcheck runs as user amandabackup so it couldn't
read /jag/cnds. But amdump runs (or its client-side daemon runs) as root so
it can read this dir regardless.
So pushing fwd and running amdump, I got errors like this:
planner: ERROR cfile-local: service sendsize: sendsize
amdump, I got errors like this:
planner: ERROR cfile-local: service sendsize: sendsize: Failed to
chdir(/jag/cnds): Permission denied
So on the client (cfile-local) I tried adding amandabackup to relevant
group to allow read/exec permission on /jag/cnds dir. But that wouldn't
work, I'm
-local: service sendsize: sendsize: Failed to
chdir(/jag/cnds): Permission denied
So on the client (cfile-local) I tried adding amandabackup to relevant group
to allow read/exec permission on /jag/cnds dir. But that wouldn't work, I'm
not sure why, possibly because the client is an NIS
this dir regardless.
So pushing fwd and running amdump, I got errors like this:
planner: ERROR cfile-local: service sendsize: sendsize: Failed to
chdir(/jag/cnds): Permission denied
So on the client (cfile-local) I tried adding amandabackup to relevant
group to allow read/exec permission
On Tue, Sep 16, 2014 at 16:45:39 -0400, Michael Stauffer wrote:
Thanks for the reply.
I presume that the errors are saying the trouble is writing the log
file on the *client* side, correct?
If I've followed your description correctly, you only made changes on
the client side, so I'd also
Hi,
I am looking at the poorman way to backup VMware guest machines. I have
a script that can do a snapshot, then move that snapshot to some disk
where Amanda can save it (then remove the snapshot).
It's ugly because it does not support any kind of granularity and only
allows full abck-up. But
Olivier,
Set
estimate server
in the dle.
Jean-Louis
On 09/15/2014 06:49 AM, Olivier Nicole wrote:
Hi,
I am looking at the poorman way to backup VMware guest machines. I have
a script that can do a snapshot, then move that snapshot to some disk
where Amanda can save it (then remove the
Jean-Louis,
Thank you.
Set
estimate server
in the dle.
But that means there is no estimae (at least the first time) while I
could provide an estimate, through a pre script, not through tar.
Best regards,
Olivier
Jean-Louis
On 09/15/2014 06:49 AM, Olivier Nicole wrote:
Hi,
I am
/maintain (if only it worked).
TIA,
Olivier
On 10/15/07, Olivier Nicole [EMAIL PROTECTED] wrote:
Hi,
Now that I can manually run sendsize, I do get the core dump.
Program received signal SIGSEGV, Segmentation fault.
0x2808f46c in debug_stralloc () from /usr/local/lib/libamanda-2.5.1p3.so
How
On 10/16/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
even without debug symbols, you should be able to get a backtrace from
gdb. Do you mind sending that on?
My bad, here it is.
Hmm .. not so helpful after all.
I configure with
./configure CFLAGS=-O0 -ggdb ...
to get debugging
Hi,
Here is the backtrace for failling sendsize:
(gdb) run
Starting program:
/usr/ports/misc/amanda-client/work/amanda-2.5.1p3/client-src/.libs/sendsize
OPTIONS maxdumps=1;hostname=ufo1000;
OPTIONS
GNUTAR /ftp 0 1970:1:1:0:0:0 0
GNUTAR /web 0 1970:1:1:0:0:0 1
GNUTAR /web 2 2007:10:5:18:16:10 1
On 10/16/07, Olivier Nicole [EMAIL PROTECTED] wrote:
If that is of any help?
It is -- it jogs my memory. This was fixed in r331 of the trunk:
r331 | djmitche | 2007-05-15 13:17:43 -0500 (Tue, 15 May 2007) | 1 line
Changed
Look in amandad.*.debug files
Check for a line with amandad: creating new service: sendsize
send all following lines starting with OPTIONS, GNUTAR or DUMP to
sendsize stdin.
Jean-Louis
Olivier Nicole wrote:
Hi,
Is there a way to manually run sendsize? What are the arguments? When
I run
Hi,
Now that I can manually run sendsize, I do get the core dump.
Program received signal SIGSEGV, Segmentation fault.
0x2808f46c in debug_stralloc () from /usr/local/lib/libamanda-2.5.1p3.so
How to recompile amanda with debuging symbols? I see nothing of the
like in the configure script
.
Dustin
On 10/15/07, Olivier Nicole [EMAIL PROTECTED] wrote:
Hi,
Now that I can manually run sendsize, I do get the core dump.
Program received signal SIGSEGV, Segmentation fault.
0x2808f46c in debug_stralloc () from /usr/local/lib/libamanda-2.5.1p3.so
How to recompile amanda with debuging
Hi,
Is there a way to manually run sendsize? What are the arguments? When
I run it by hand (with no arguments) nothing happens and it sits there
for ages, when it is called via amandad, it will coredump almost at
once.
Olivier
Jean-Louis Martineau [EMAIL PROTECTED] writes:
If sendsize is not running, it's because it crashed.
Hmm, it's definitely not running, but I don't see any trace of a crash.
Is there more verbose logging that can be turned on somewhere?
I don't understand why amandad finish before sendsize, can
ICT 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386
and last night bacup failed with sendsize coredump.
kernel: Oct 12 00:50:59 ufo kernel: pid 64313 (sendsize), uid 14: exited on
signal 11 (core dumped)
While I am looking at it, any idea about where I could search is welcome
Paul Lussier wrote:
You should add a spindle for dle on the same physical disk, it can be
a lot faster.
I don't understand this statement. Could you clarify please?
man amanda
search for spindle
All DLE of a physical disk should have the same spindle (0).
It's generally faster to run
ufo.cs.ait.ac.th 5.5-RELEASE-p15 FreeBSD 5.5-RELEASE-p15 #7: Wed Oct
3 10:17:29 ICT 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386
and last night bacup failed with sendsize coredump.
kernel: Oct 12 00:50:59 ufo kernel: pid 64313 (sendsize), uid 14: exited on
signal 11 (core
On 2007-10-12 15:45, Paul Lussier wrote:
---
amanda have a timeout of 6 hours (21600 seconds).
Can you point me to where in the docs this is mentioned? I've never
seen this menioned before (though I wasn't really looking for it) and
I can't seem to find it anywhere right now (running on
.
---
amandad: time 21603.544: /usr/local/libexec/sendsize timed out waiting
for REP data
amandad: time 21603.781: sending NAK pkt:
ERROR timeout on reply pipe
---
amanda have a timeout of 6 hours (21600 seconds).
Can you
the amandad and
sendsize to cooperate.
Are you suggesting this is currently possible, or that it might be a
good solution for the future?
for future.
That's what I suspected.
Thank you for all your help. I've recompiled with a higher
REP_TIMEOUT (15) and am re-running the test to be sure that's
Jean-Louis Martineau [EMAIL PROTECTED] writes:
Paul Lussier wrote:
Can you point me to where in the docs this is mentioned?
It's not documented, it's not a server limit, it's a client limit we
added do be sure amandad will eventually terminate.
Ahh, that's why I never knew about it :)
Why you never posted the error in the amandad debug file?
---
amandad: time 21603.544: /usr/local/libexec/sendsize timed out waiting
for REP data
amandad: time 21603.781: sending NAK pkt:
ERROR timeout on reply pipe
.
---
amandad: time 21603.544: /usr/local/libexec/sendsize timed out waiting
for REP data
amandad: time 21603.781: sending NAK pkt:
ERROR timeout on reply pipe
---
amanda have a timeout of 6
Tuesday night at Tue Oct 9 22:48:34 2007.
According the /var/log/amanda/amandad/amandad.20071009224834.debug file:
amandad: time 21604.147: pid 26218 finish time Wed Oct 10 04:48:39 2007
According to sendsize.20071009224835.debug:
amanda2:/var/log/amanda/client/offsite# tail sendsize
The seems a bit similar to firewall issues we had a while back ---
the sendsize estimate took long enough that the connection FROM the
server was closed. The firewall only allowed connections made by the
server, or replies back through the same connection... and needed to be
opened
now. I started amanda off Tuesday night at Tue Oct 9 22:48:34 2007.
According the /var/log/amanda/amandad/amandad.20071009224834.debug file:
amandad: time 21604.147: pid 26218 finish time Wed Oct 10 04:48:39 2007
According to sendsize.20071009224835.debug:
amanda2:/var/log/amanda/client
Hi all,
I'm using amanda 2.5.1p1-2.1 from Debian/stable.
I have several file systems which take hours to estimate and dump.
My amanda.conf contains:
etimeout 10800 # 3 hours
dtimeout 7200 # 2 hours
ctimeout 30
My sendsize log reports the following:
$ egrep estimate (time|size
Paul Lussier wrote:
Hi all,
I'm using amanda 2.5.1p1-2.1 from Debian/stable.
I have several file systems which take hours to estimate and dump.
My amanda.conf contains:
etimeout 10800 # 3 hours
dtimeout 7200 # 2 hours
ctimeout 30
My sendsize log reports the following:
$ egrep
Paul Lussier wrote:
Jean-Louis Martineau [EMAIL PROTECTED] writes:
Look at the amdump log file, it list all estimate received from the clients.
Are you sure the sendsize debug file you look at is the correct one?
sendsize will continue even after an estimate timeout.
It was the only
send me the complete amdump log file, planner.*.debug,
amandad.*.debug and sendsize.*.debug?
Sure, they're all attached.
Jean-Louis Martineau [EMAIL PROTECTED] writes:
It's weird.
Do you have an amdump log file or just amdump.1?
The only way to get this is if you killed amanda process on the
server, maybe a server crash.
Do you still have amanda process running on the server?
No, the reason it's a .1 is
Toralf Lund wrote:
Forgot to answer this earlier, I think...
If you can't kill sendsize, it's because it is hang in a system call.
It's often when it try to access a mount point.
Do you have a hanged mount point?
But yes, you are absolutely right. The host in question had problems
with an NFS
Forgot to answer this earlier, I think...
If you can't kill sendsize, it's because it is hang in a system call.
It's often when it try to access a mount point.
Do you have a hanged mount point?
But yes, you are absolutely right. The host in question had problems
with an NFS mount. I didn't
If you can't kill sendsize, it's because it is hang in a system call.
It's often when it try to access a mount point.
Do you have a hanged mount point?
did df also hang?
Jean-Louis
Toralf Lund wrote:
We just started to get a serious problem with our amdump execution
(Amanda 2.5.0p2). As usual
on waitq]
2. sendsize on the host in question hangs, and I mean really hangs
- not even 'kill -9' will stop it.
3. The amandad.id.debug on this host (fileserv) says:
amandad: time 14027.090: sending ACK pkt:
amandad: time 21600.297: /usr/freeware/libexec/sendsize timed out
Not sure if this is to do with the FreeBSD port but upgrading to 2.5.1p3
from p2 and the dump estimate has stopped working. Here is the debug output
from client sendsize.
sendsize[43898]: time 1.025: calculating for device /dev/da0s1a with ufs
sendsize[43898]: time 1.025: running /sbin/dump
is already in the CVS.
Jean-Louis
Chris Stenton wrote:
Not sure if this is to do with the FreeBSD port but upgrading to
2.5.1p3 from p2 and the dump estimate has stopped working. Here is
the debug output from client sendsize.
sendsize[43898]: time 1.025: calculating for device /dev/da0s1a with ufs
to
2.5.1p3 from p2 and the dump estimate has stopped working. Here is
the debug output from client sendsize.
sendsize[43898]: time 1.025: calculating for device /dev/da0s1a with
ufs
sendsize[43898]: time 1.025: running /sbin/dump 1SSsf 0 1048576 -
/dev/da0s1a
sendsize[43898]: time 1.026: running
--
Hi all,
My first post here. I have perused all resources I know of to answer
this question, but results have been very limited. Forgive me if this
question has been posed and answer prior, but I cannot find the answer.
My issue is a sendsize timeout error. When it happens, amstatus shows
Hi all,
My first post here. I have perused all resources I know of to answer
this question, but results have been very limited. Forgive me if this
question has been posed and answer prior, but I cannot find the answer.
My issue is a sendsize timeout error. When it happens, amstatus shows
John E Hein wrote:
This has been working for me for the past 4+ years. But if I ever
start hitting the ~64 KiB udp per socket limit, something else will
have to be tried (as described in the above message).
As of Amanda 2.5.1, we have added bsdtcp auth which uses tcp exclusively. As a
I am currently working with amanda2.5.1-p1 on a HPUX 11.11
machine. I seem to be getting my packets truncated to about 1024 bytes or so
between the planner and the sendsize routine. This is much less than the
32768 byte limits mentioned in other posts. I may be having a problem
1024 bytes or so
between the planner and the sendsize routine. This is much less than
the 32768 byte limits mentioned in other posts. I may be having a
problem with the code that splits up the packets , mentioned in a
previous post there is a diff/patch that sets the max size to 65535
, but the infamous estimate failed keeps happening when I
actually try to run. It's not a timeout (total execution is only 30
seconds), and sendsize seems to be actively failing. I'm not sure what
to make of it. In particular:
* /sbin/dump 0Ssf 1048576 - /dev/sda1 works fine as the amanda
trying to add a Fedora 4 client, with poor results. amcheck
runs fine, but the infamous estimate failed keeps happening when I
actually try to run. It's not a timeout (total execution is only 30
seconds), and sendsize seems to be actively failing. I'm not sure what
to make
Matt Hyclak wrote:
If I had to guess, I'd say you've got SELinux enabled and it's
interfering.
Anything in /var/log/messages to tell if that's the case?
No messages, but we have a winner anyway. I kicked SELinux down to warn
mode and *poof* now amanda works.
That will teach me to turn
client, with poor results. amcheck
runs fine, but the infamous estimate failed keeps happening when I
actually try to run. It's not a timeout (total execution is only 30
seconds), and sendsize seems to be actively failing. I'm not sure
what to make of it. In particular:
* /sbin/dump
You're incorrect regarding how I built it, as this was the standard
binary install via YUM. My natural expectation, proven by the
suggestion on SELinux, is that the package was built and installed
properly, but my environment had other issues.
One does not need to build it as the user who
:
if /afs is mounted, the sendsize debug information contains:
sendsize[21534]: argument list: /usr/pkg/bin/gtar --create --file
/dev/null --directory /afs --one-file-system --listed-incremental
/var/amanda/gnutar-lists/wpdu2.physik.uni-wuppertal.de_wwwhome_alicenext_0.new
--sparse --ignore-failed
This is the ONLY DLE for wpdu2!
Now something strange happens:
if /afs is mounted, the sendsize debug information contains:
sendsize[21534]: argument list: /usr/pkg/bin/gtar --create --file
/dev/null --directory /afs --one-file-system --listed-incremental
/var/amanda/gnutar-lists/wpdu2.physik.uni
Paul Bijnens wrote:
Amanda uses /etc/(v)fstab to map devices to directories and vice versa.
Is there some mapping there that results in /home being mapped to /afs?
Hi Paul,
thanks a lot for your quick reply.
Okay:
our fstab looks like this:
/dev/sd0a / ffs rw 1 1
/dev/wd0a /usr ffs
I have amanda 2.4.5 install on a FC4 machine. I plan to use this machine to
backup several Windows 2K and XP machines. It is replacing a machine that is
running amanda 2.4.4 running on FC2.
The new machine has smbclient 3.0.14a-2, while the old has 3.0.10-1.fc2. I have
not been able to get
I have been able to backup one of our WinNT servers, server1, with
amanda without problems. But, when I add a second WinNT server, server2,
sendsize never finishes. /tmp/amanda/sendsize.20050520190001.debug shows
the server1 DLE estimates finishing normally, but server2 starts out
like
/amanda/exclude.gtar
priority medium
}
The file system should compress to around 17Gb and will fit on the
tape no problem. I had a look at the sendsize report and it showed
that during the size estimate, it didn't use compression.
sendsize: argument list: /bin/tar --create --file /dev/null
a look at the sendsize report and it showed that
during the size estimate, it didn't use compression.
sendsize: argument list: /bin/tar --create --file /dev/null --directory
/home --one-file-system --listed-incremental
/var/lib/amanda/gnutar-lists/fs0_home_0.new --sparse
--ignore-failed-read
to around 17Gb and will fit on the tape
no problem. I had a look at the sendsize report and it showed that
during the size estimate, it didn't use compression.
sendsize: argument list: /bin/tar --create --file /dev/null --directory
/home --one-file-system --listed-incremental
/var/lib/amanda/gnutar
Hi Stefan, Charlie et al,...
...and at first, thanks for your hints / recommendations. Actually,
after frequently being stuck with sendsize, I once again checked all
my configuration, run amcheck to fix up three or four errors in my
disklist (caused by missing blanks, like
localhost sql
, at least as I read in various mailing lists, it's not
possible to make amanda dump file systems across multiple tapes).
Most of the things seem to work fine, amdump itself starts, spawns
several dumper-processes and launches an amandad which starts
sendsize and does a tar across the filesystem
and launches an amandad which starts
KR sendsize and does a tar across the filesystem to be backed up. Some
KR minutes later, all the processes ended again, nothing has been
KR written to any tape, and I am grepping around the amanda
KR documentation, being pretty clueless where to look at, now. Can
On Tue, 24 Feb 2004 at 2:59pm, Kristian Rink wrote
Most of the things seem to work fine, amdump itself starts, spawns
several dumper-processes and launches an amandad which starts
sendsize and does a tar across the filesystem to be backed up. Some
minutes later, all the processes ended again
an amandad which starts
sendsize and does a tar across the filesystem to be backed up. Some
minutes later, all the processes ended again, nothing has been
written to any tape, and I am grepping around the amanda
documentation, being pretty clueless where to look at, now. Can
someone enlighten me
read in various mailing lists, it's not
possible to make amanda dump file systems across multiple tapes).
Most of the things seem to work fine, amdump itself starts, spawns
several dumper-processes and launches an amandad which starts
sendsize and does a tar across the filesystem to be backed up
Hello,
I am using amanda 2.4.4p1 on a AIX 4.3.3 IBM RS6000. I have compiled it
with both, the ibm coompiler en gcc 2.95.3. The both gave me an unusable
sendsize command. This command end in a coredmp. For some obscure raison
the executable crash on the call to amroflock, dont know why (seem
Didierjean Fabrice wrote:
Hello,
I am using amanda 2.4.4p1 on a AIX 4.3.3 IBM RS6000. I have compiled it
with both, the ibm coompiler en gcc 2.95.3. The both gave me an unusable
sendsize command. This command end in a coredmp. For some obscure raison
the executable crash on the call to amroflock
On Tue, Dec 02, 2003 at 11:39:39AM +0100, Didierjean Fabrice wrote:
Hello,
I am using amanda 2.4.4p1 on a AIX 4.3.3 IBM RS6000. I have compiled it
with both, the ibm coompiler en gcc 2.95.3. The both gave me an unusable
sendsize command. This command end in a coredmp. For some obscure raison
-2.04# pwd
/opt-net/amanda/AIX/libexec
bash-2.04# ldd sendsize
/opt-net/amanda/AIX/lib/libamclient.a(libamclient-2.4.4p1.so)
/usr/lib/libintl.a(shr.o)
/opt-net/amanda/AIX/lib/libamanda.a(libamanda-2.4.4p1.so)
/usr/lib/libc.a(pse.o)
/usr/lib/libtli.a(shr.o)
/usr/lib/libpthreads.a(shr.o)
/usr/lib
?
Don
Donald L. (Don) Ritchey
E-mail: [EMAIL PROTECTED]
-Original Message-
From: Jon LaBadie [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 13, 2003 2:19 PM
To: [EMAIL PROTECTED]
Subject: Re: [LONG] Amanda Tru64 V5.1A client sendsize, /sbin/dump fails
On Thu, Feb 13, 2003 at 06:14
On Thu, 13 Feb 2003 at 6:14pm, Sean McGeever wrote
Tru64-client sendsize.debug:
sendsize: debug 1 pid 268247 ruid 203 euid 203 start time Thu Feb 13
17:39:50 2003
/usr/local/libexec/sendsize: version 2.4.2p2
calculating for amname '/', dirname '/'
sendsize: getting size via dump
On Fri, 14 Feb 2003 at 1:19pm, Sean McGeever wrote
Tru64-client sendsize.debug:
I know nothing of Tru64, but...
sendsize: debug 1 pid 268247 ruid 203 euid 203 start time Thu Feb 13
17:39:50 2003
/usr/local/libexec/sendsize: version 2.4.2p2
calculating for amname '/', dirname
On Fri, Feb 14, 2003 at 09:14:41AM -0500, Joshua Baker-LePain wrote:
On Fri, 14 Feb 2003 at 1:19pm, Sean McGeever wrote
Tru64-client sendsize.debug:
I know nothing of Tru64, but...
[snip]
sendsize: running /sbin/dump 0Ssf 1048576 - /dev/rdisk/dsk0a
At least on Linux, the S flag
stage
(i.e., sendsize). 'amcheck Daily' when run on the amanda server reports
no error when checking the Tru64 client machine.
Logs:
-
amanda-server amdump log:
amdump: start at Thu Feb 13 15:31:42 GMT 2003
planner: pid 21505 executable /usr/local/libexec/amanda/planner version 2.4.2p2
1 - 100 of 120 matches
Mail list logo
