RE: amandad paths
Thanks Jose, when I find time I will be making the ansible role smarter. It will detect which of the amandad paths is needed (for the host being configured) by searching through a list. These entries will be part of that search. - David Simpson - Senior Systems Engineer ARCCA, Redwood Building, King Edward VII Avenue, Cardiff, CF10 3NB David Simpson - peiriannydd uwch systemau ARCCA, Adeilad Redwood, King Edward VII Avenue, Caerdydd, CF10 3NB -Original Message- From: Jose M Calhariz Sent: 17 November 2021 13:27 To: David Simpson Cc: amanda-users@amanda.org Subject: Re: amandad paths External email to Cardiff University - Take care when replying/opening attachments or links. Nid ebost mewnol o Brifysgol Caerdydd yw hwn - Cymerwch ofal wrth ateb/agor atodiadau neu ddolenni.
Re: amandad paths
Let me add what dumptypes I have:
define dumptype bsd {
amandad_path "/usr/local/libexec/amanda/amandad"
client_username "amanda"
}
define dumptype rhel {
amandad-path "/usr/lib64/amanda/amandad"
client_username "amandabackup"
}
define dumptype osx {
client_username "amandabackup"
}
define dumptype upstream {
amandad-path "/usr/libexec/amanda/amandad"
client_username "amandabackup"
}
define dumptype source {
amandad-path "/usr/local/libexec/amanda"
client_username "amanda"
}
Kind regards
Jose M Calhariz
On Thu, Nov 11, 2021 at 04:47:25PM +, David Simpson wrote:
> Appear to have come across 3 possible amandad paths so far:
>
>
> Debian 11 (from repo): /usr/lib/amanda/amandad
>
> Alamlinux 8 (from repo @appstream): /usr/lib64/amanda/amandad
>
> RedHat 7 Zmanda supplied RPM (from website): /usr/libexec/amanda/amandad
>
>
>
> Do these cover all known (and current) combinations/everything?
>
> David
>
>
>
> -
> David Simpson - Senior Systems Engineer
> ARCCA, Redwood Building,
> King Edward VII Avenue,
> Cardiff, CF10 3NB
>
> David Simpson - peiriannydd uwch systemau
> ARCCA, Adeilad Redwood,
> King Edward VII Avenue,
> Caerdydd, CF10 3NB
--
--
Bill Gates e Scott McNealy estavam jogando frisbee perto de um lago.
Constantemente, Bill, demonstrando horrível pontaria, jogava muito alto e o
frisbee caía no meio do lago. Scott ia até lá, andava sobre a água e buscava o
frisbee, e o jogo prosseguia.
Na manhã seguinte, a Microsoft publica dois press-releases:
- Lançamentos da Microsoft superam expectativas!
- Scott não sabe nadar
signature.asc
Description: PGP signature
amandad paths
Appear to have come across 3 possible amandad paths so far: Debian 11 (from repo): /usr/lib/amanda/amandad Alamlinux 8 (from repo @appstream): /usr/lib64/amanda/amandad RedHat 7 Zmanda supplied RPM (from website): /usr/libexec/amanda/amandad Do these cover all known (and current) combinations/everything? David - David Simpson - Senior Systems Engineer ARCCA, Redwood Building, King Edward VII Avenue, Cardiff, CF10 3NB David Simpson - peiriannydd uwch systemau ARCCA, Adeilad Redwood, King Edward VII Avenue, Caerdydd, CF10 3NB
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.github.com/rreilly-edr/4f9f7373049124b28fd1da75ffcfe917 Robert, did you ever have any luck tracking down what was causing the calcsize hangs in your environment? Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
Re: amandad defunct on client calcsize/sendsize hung
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 It would still be helpeful to see your actual disklist file, but it looks like you have two Amanda clients configured via SSH and one using BSDTCP auth. In the successful run, all three clients respond to the "estimate server" request essentially immediately and the planner shuts down cleanly, around 2 seconds after it starts. In the failed run, the BSDTCP client reponds with its size estimates within about 18 seconds, but the other two clients never send any calcsize data back to the planner, and after (I believe) the etimeout period expires the planner gives up and shuts down. So, I guess the next thing to look at is the exact status of the "calcsize" 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-driver -> planner), so it could be somewhere in there Or it could be that "calcsize" just isn't running/terminating, for some reason (though this seems less likely, since the problem seems to have something to do with upgrading to 3.5.1 on the server side...). Anyway, in addition to looking at processes on the client and strace/lsof of the calcsize (and sendsize) processes during the waiting period, more generally looking at the "sendsize" debug files on the clients might tell us have far along the clients are getting and if there are any errors along the way. Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
Re: amandad defunct on client calcsize/sendsize hung
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 post your disklist file? (I take it it has only four entries, right?) I will try to take a closer look at the planner logs later today... Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
RE: amandad defunct on client calcsize/sendsize hung
First one is the failed backup second is the successful backup https://gist.github.com/rreilly-edr/debff9f0ce3a1759993083b54a966cda -Original Message- From: owner-amanda-us...@amanda.org On Behalf Of Nathan Stratton Treadway Sent: Friday, September 20, 2019 9:21 AM To: amanda-users@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.github.com/rreilly-edr/4f9f7373049124b28fd1da75ffcfe917 Can you post the planner log from the successful estimate-server run as well? We might learn something more by comparing the two Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
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.github.com/rreilly-edr/4f9f7373049124b28fd1da75ffcfe917 Can you post the planner log from the successful estimate-server run as well? We might learn something more by comparing the two Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
RE: amandad defunct on client calcsize/sendsize hung
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 -Original Message- From: owner-amanda-us...@amanda.org On Behalf Of Nathan 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 just a wrapper that kicks of several other components to do the real work. In this case, it's the *planner* log on the server side that would show 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-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
RE: amandad defunct on client calcsize/sendsize hung
Nathan, I will try with the server estimate, also I am able to run calcsize manually with no problem. I will try this now and report back. Thanks Robert -Original Message- From: owner-amanda-us...@amanda.org On Behalf Of Nathan Stratton Treadway Sent: Thursday, September 19, 2019 9:56 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 8829 0 17:45 ?00:00:00 sshd: backup@notty > backup8928 8919 0 17:45 ?00:00:00 /usr/lib/amanda/amandad > -auth=ssh > backup9056 8928 0 17:45 ?00:00:00 [noop] > backup9057 8928 0 17:45 ? 00:00:00 [amandad] (I am not sure how long you had between cycles of your while loop, but I as far as I can tell it's normal operation for the spawned "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 happen with the "sendsize" process -- but since that is never finishing you never get to the point that there's a defunct sendsize process. Then defunct "amandad" processes, on the other hand, seem to be subproceses amandad spawns of itself to offload some work -- and as far as I can tell those may not get cleaned up until amandad as a whole exits.) Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
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 just a wrapper that kicks of several other components to do the real work. In this case, it's the *planner* log on the server side that would show 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-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
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 8829 0 17:45 ?00:00:00 sshd: backup@notty > backup8928 8919 0 17:45 ?00:00:00 /usr/lib/amanda/amandad > -auth=ssh > backup9056 8928 0 17:45 ?00:00:00 [noop] > backup9057 8928 0 17:45 ? 00:00:00 [amandad] (I am not sure how long you had between cycles of your while loop, but I as far as I can tell it's normal operation for the spawned "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 happen with the "sendsize" process -- but since that is never finishing you never get to the point that there's a defunct sendsize process. Then defunct "amandad" processes, on the other hand, seem to be subproceses amandad spawns of itself to offload some work -- and as far as I can tell those may not get cleaned up until amandad as a whole exits.) Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
Re: amandad defunct on client calcsize/sendsize hung
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 sure what other debug logs make sense to send.. I take it you did set etimeout to "3600"? Looks like what's happening now is that the Amanda server side times out (after that 1 hour period) when it hasn't heard back from the client, whereas before it was amandad on the client which timed out (after 5.5 hours). But both would seem to be consistent with the underlying problem of calcsize never completing, for whatever reason... Have you tried switching to e.g. "estimate server" on one of the affected DLEs? That would give a hint as to whether the problem is with "calcsize" per se or a more general problem with communication between the clinet and the server. (That is, with "estimate server" the client shoudln't need to run calcsize and thus there wouldn't be a calcsize process to get stuck... but then does the same thing happen with the next activity that the client tries to do?) Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
Re: amandad defunct on client calcsize/sendsize hung
On Thu, Sep 12, 2019 at 17:30:44 +, Robert Reilly wrote: > 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 to figure out why 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 ?00:00:00 (sd-pam) > backup 20255 20206 0 17:18 ?00:00:00 sshd: backup@notty > backup 20256 20255 0 17:18 ?00:00:00 /usr/lib/amanda/amandad > -auth=ssh > backup 20261 20256 0 17:18 ?00:00:00 [amandad] > backup 20288 20256 0 17:18 ?00:00:00 /usr/lib/amanda/sendsize > amandad ssh > backup 20289 20256 0 17:18 ?00:00:00 [amandad] > backup 20290 20288 0 17:18 ?00:00:00 /usr/lib/amanda/sendsize > amandad ssh > backup 20291 20288 0 17:18 ?00:00:00 /usr/lib/amanda/sendsize > amandad ssh > backup 20292 20290 0 17:18 ?00:00:00 calcsize DailySet1 GNUTAR / / > 0 0 > backup 20293 20291 0 17:18 ?00:00:00 calcsize DailySet1 GNUTAR > /opt /opt 0 0 I'm still trying to look though all the emails and linked log files in this thread, but may not be able to do that today, so thought I would sent a quick note for now: I don't use ssh auth myself and it's not currently clear to me why there would be two defunct amandad processes like this, but amandad definitely spawns subprocesses for each "service" it's running, and I'm fairly certain that it doesn't reap child processes until it is shutting down So in this case I think the fact that there are defunct amandad processes is probably just a harmless side-effect of the true problem, which seems to be that the calcsize proceses aren't finishing. Are you still getting this same behavior? Can you lsof/strace the calcsize process and/or look closely in the /var/log/amanda/client/DailySet1/sendsize.*.debug log to find out what it causing it to hang? (Once you've finished investigating the calcisize processes, you could test my first theory by killing those processes and seeing if amandad at that point cleans up the defunct processes and exits cleanly...) Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
Re: amandad defunct on client calcsize/sendsize hung
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 server I am curious if it is my problem (see: https://www.mail-archive.com/amanda-users@amanda.org/msg49744.html) KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html There are no manifestos like cannon and musketry. -- The Duke of Wellington
RE: amandad defunct on client calcsize/sendsize hung
I did a while loop started the backup and I see that noop is also defunct but dose get cleaned up backup8919 8829 0 17:45 ?00:00:00 sshd: backup@notty backup8928 8919 0 17:45 ?00:00:00 /usr/lib/amanda/amandad -auth=ssh backup9056 8928 0 17:45 ?00:00:00 [noop] backup9057 8928 0 17:45 ?00:00:00 [amandad] Rob -Original Message- From: owner-amanda-us...@amanda.org On Behalf Of Robert Reilly Sent: Thursday, September 12, 2019 1:31 PM To: Kamil Jońca ; amanda-users@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 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 ?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 ?00:00:00 (sd-pam) backup 20255 20206 0 17:18 ?00:00:00 sshd: backup@notty backup 20256 20255 0 17:18 ?00:00:00 /usr/lib/amanda/amandad -auth=ssh backup 20261 20256 0 17:18 ?00:00:00 [amandad] backup 20288 20256 0 17:18 ?00:00:00 /usr/lib/amanda/sendsize amandad ssh backup 20289 20256 0 17:18 ?00:00:00 [amandad] backup 20290 20288 0 17:18 ?00:00:00 /usr/lib/amanda/sendsize amandad ssh backup 20291 20288 0 17:18 ?00:00:00 /usr/lib/amanda/sendsize amandad ssh backup 20292 20290 0 17:18 ?00:00:00 calcsize DailySet1 GNUTAR / / 0 0 backup 20293 20291 0 17:18 ?00:00:00 calcsize DailySet1 GNUTAR /opt /opt 0 0 -Original Message- From: owner-amanda-us...@amanda.org On Behalf Of Kamil Jonca Sent: Thursday, September 12, 2019 1:05 PM To: amanda-users@amanda.org Subject: Re: amandad defunct on client calcsize/sendsize hung 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 -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html Epperson's law: When a man says it's a silly, childish game, it's probably something his wife can beat him at.
RE: amandad defunct on client calcsize/sendsize hung
All, Is there a way to run the backup manually to see whats happening on the client outside of running strace on amdump ? Rob -Original Message- From: owner-amanda-us...@amanda.org On Behalf Of Robert Reilly Sent: Thursday, September 12, 2019 1:31 PM To: Kamil Jońca ; amanda-users@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 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 ?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 ?00:00:00 (sd-pam) backup 20255 20206 0 17:18 ?00:00:00 sshd: backup@notty backup 20256 20255 0 17:18 ?00:00:00 /usr/lib/amanda/amandad -auth=ssh backup 20261 20256 0 17:18 ?00:00:00 [amandad] backup 20288 20256 0 17:18 ?00:00:00 /usr/lib/amanda/sendsize amandad ssh backup 20289 20256 0 17:18 ?00:00:00 [amandad] backup 20290 20288 0 17:18 ?00:00:00 /usr/lib/amanda/sendsize amandad ssh backup 20291 20288 0 17:18 ?00:00:00 /usr/lib/amanda/sendsize amandad ssh backup 20292 20290 0 17:18 ?00:00:00 calcsize DailySet1 GNUTAR / / 0 0 backup 20293 20291 0 17:18 ?00:00:00 calcsize DailySet1 GNUTAR /opt /opt 0 0 -Original Message- From: owner-amanda-us...@amanda.org On Behalf Of Kamil Jonca Sent: Thursday, September 12, 2019 1:05 PM To: amanda-users@amanda.org Subject: Re: amandad defunct on client calcsize/sendsize hung 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 -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html Epperson's law: When a man says it's a silly, childish game, it's probably something his wife can beat him at.
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 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 ?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 ?00:00:00 (sd-pam) backup 20255 20206 0 17:18 ?00:00:00 sshd: backup@notty backup 20256 20255 0 17:18 ?00:00:00 /usr/lib/amanda/amandad -auth=ssh backup 20261 20256 0 17:18 ?00:00:00 [amandad] backup 20288 20256 0 17:18 ?00:00:00 /usr/lib/amanda/sendsize amandad ssh backup 20289 20256 0 17:18 ?00:00:00 [amandad] backup 20290 20288 0 17:18 ?00:00:00 /usr/lib/amanda/sendsize amandad ssh backup 20291 20288 0 17:18 ?00:00:00 /usr/lib/amanda/sendsize amandad ssh backup 20292 20290 0 17:18 ?00:00:00 calcsize DailySet1 GNUTAR / / 0 0 backup 20293 20291 0 17:18 ?00:00:00 calcsize DailySet1 GNUTAR /opt /opt 0 0 -Original Message- From: owner-amanda-us...@amanda.org On Behalf Of Kamil Jonca Sent: Thursday, September 12, 2019 1:05 PM To: amanda-users@amanda.org Subject: Re: amandad defunct on client calcsize/sendsize hung 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 -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html Epperson's law: When a man says it's a silly, childish game, it's probably something his wife can beat him at.
Re: amandad defunct on client calcsize/sendsize hung
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 -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html Epperson's law: When a man says it's a silly, childish game, it's probably something his wife can beat him at.
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 with them under Debian and Ubuntu in the past. Maybe it would help to build amanda from the source tarball? Not directly related to your problem (I think) but probably of interest if you are using package amanda-client on Ubuntu 18.04: https://utcc.utoronto.ca/~cks/space/blog/linux/Ubuntu1804AmandaProblem Jens On 9/11/2019 6:34 PM, Robert Reilly wrote: > I added the timeouts but still see the following in the amandad log and > backup does not complete and the procs are still defunct. If I run > caclsize manually completes: > > time ./calcsize DailySet1 GNUTAR / / 0 0 > > / 0 SIZE 3472863 > > > > real 0m0.428s > > user 0m0.132s > > sys 0m0.292s > > > > “Wed Sep 11 15:59:02 2019: thd-0x5575c3fe1400: amandad: receive error: > EOF on read from tf-p-ubu-amanda-00.xx.com” > > > > *From:* owner-amanda-us...@amanda.org > *On Behalf Of *Robert Reilly > *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 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:owner-amanda-us...@amanda.org> <mailto:owner-amanda-us...@amanda.org>> *On Behalf Of *Robert Reilly > *Sent:* Friday, September 6, 2019 10:55 AM > *To:* amanda-users@amanda.org <mailto: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 > > Amanda 3.3.6 > > > > Immediately after starting the backup this is the state of the procs on > the client > > backup 30608 1 0 11:36 ? 00:00:00 /lib/systemd/systemd --user > > backup 30609 30608 0 11:36 ? 00:00:00 (sd-pam) > > backup 30645 30606 0 11:36 ? 00:00:00 sshd: backup@notty > > backup 30646 30645 0 11:36 ? 00:00:00 /usr/lib/amanda/amandad > -auth=ssh > > backup 30648 30646 0 11:36 ? 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/rreilly-edr/0fd11aff9cb4e157b614cf74c9b51ddb > > > > # > > > > Client Debug Log > > > > https://gist.github.com/rreilly-edr/37ea6314b19ecc96f31c3d846df0219d > > > > ## > > Thanks in advance.. > > Robert > > > > >
Re: amandad defunct on client calcsize/sendsize hung
Hi, the hanging processes are strange, no idea about that. But I noticed you haven't defined "etimeout" (the time amanda waits for estimate results in seconds) in your amanda.conf. IIRC it defaults to something around 10 min. and that might be too short for the client. Does it help to set etimeout 3600 in amanda.conf? If yes, it's probably a good idea to define "dtimeout" as well and set it to twice or thrice the value of etimeout. Jens On 9/11/2019 2:30 PM, Robert Reilly wrote: > 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 > *On Behalf Of *Robert Reilly > *Sent:* Friday, 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 > > Amanda 3.3.6 > > > > Immediately after starting the backup this is the state of the procs on > the client > > backup 30608 1 0 11:36 ? 00:00:00 /lib/systemd/systemd --user > > backup 30609 30608 0 11:36 ? 00:00:00 (sd-pam) > > backup 30645 30606 0 11:36 ? 00:00:00 sshd: backup@notty > > backup 30646 30645 0 11:36 ? 00:00:00 /usr/lib/amanda/amandad > -auth=ssh > > backup 30648 30646 0 11:36 ? 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/rreilly-edr/0fd11aff9cb4e157b614cf74c9b51ddb > > > > # > > > > Client Debug Log > > > > https://gist.github.com/rreilly-edr/37ea6314b19ecc96f31c3d846df0219d > > > > ## > > Thanks in advance.. > > Robert > > > > >
RE: amandad defunct on client calcsize/sendsize hung
Jens, I am using the included packages was trying to quickly POC Amanda for our env for a few file servers. I will build from source and see if I get anywhere. Thanks ! rob -Original Message- From: Jens Berg Sent: Thursday, September 12, 2019 3:19 AM To: Robert Reilly ; amanda-users@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 with them under Debian and Ubuntu in the past. Maybe it would help to build amanda from the source tarball? Not directly related to your problem (I think) but probably of interest if you are using package amanda-client on Ubuntu 18.04: https://utcc.utoronto.ca/~cks/space/blog/linux/Ubuntu1804AmandaProblem Jens On 9/11/2019 6:34 PM, Robert Reilly wrote: > I added the timeouts but still see the following in the amandad log > and backup does not complete and the procs are still defunct. If I run > caclsize manually completes: > > time ./calcsize DailySet1 GNUTAR / / 0 0 > > / 0 SIZE 3472863 > > > > real 0m0.428s > > user 0m0.132s > > sys 0m0.292s > > > > "Wed Sep 11 15:59:02 2019: thd-0x5575c3fe1400: amandad: receive error: > EOF on read from tf-p-ubu-amanda-00.xx.com" > > > > *From:* owner-amanda-us...@amanda.org > *On Behalf Of *Robert Reilly > *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 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:owner-amanda-us...@amanda.org> <mailto:owner-amanda-us...@amanda.org>> *On Behalf Of *Robert Reilly > *Sent:* Friday, September 6, 2019 10:55 AM > *To:* amanda-users@amanda.org <mailto: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 > > Amanda 3.3.6 > > > > Immediately after starting the backup this is the state of the procs > on the client > > backup 30608 1 0 11:36 ? 00:00:00 /lib/systemd/systemd > --user > > backup 30609 30608 0 11:36 ? 00:00:00 (sd-pam) > > backup 30645 30606 0 11:36 ? 00:00:00 sshd: backup@notty > > backup 30646 30645 0 11:36 ? 00:00:00 > /usr/lib/amanda/amandad -auth=ssh > > backup 30648 30646 0 11:36 ? 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/rreilly-edr/0fd11aff9cb4e157b614cf74c9b51ddb > > > > # > > > > Client Debug Log > > > > https://gist.github.com/rreilly-edr/37ea6314b19ecc96f31c3d846df0219d > > > > ## > > Thanks in advance.. > > Robert > > > > >
RE: amandad defunct on client calcsize/sendsize hung
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 sure what other debug logs make sense to send.. Thanks Rob -Original 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- 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 that. But I noticed you haven't defined "etimeout" (the time amanda waits for estimate results in seconds) in your amanda.conf. IIRC it defaults to something around 10 min. and that might be too short for the client. Does it help to set etimeout 3600 in amanda.conf? If yes, it's probably a good idea to define "dtimeout" as well and set it to twice or thrice the value of etimeout. Jens On 9/11/2019 2:30 PM, Robert Reilly wrote: > 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 > *On Behalf Of *Robert Reilly > *Sent:* Friday, 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 > > Amanda 3.3.6 > > > > Immediately after starting the backup this is the state of the procs > on the client > > backup 30608 1 0 11:36 ? 00:00:00 /lib/systemd/systemd > --user > > backup 30609 30608 0 11:36 ? 00:00:00 (sd-pam) > > backup 30645 30606 0 11:36 ? 00:00:00 sshd: backup@notty > > backup 30646 30645 0 11:36 ? 00:00:00 > /usr/lib/amanda/amandad -auth=ssh > > backup 30648 30646 0 11:36 ? 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/rreilly-edr/0fd11aff9cb4e157b614cf74c9b51ddb > > > > # > > > > Client Debug Log > > > > https://gist.github.com/rreilly-edr/37ea6314b19ecc96f31c3d846df0219d > > > > ## > > Thanks in advance.. > > Robert > > > > >
RE: amandad defunct on client calcsize/sendsize hung
I added the timeouts but still see the following in the amandad log and backup does not complete and the procs are still defunct. If I run caclsize manually completes: time ./calcsize DailySet1 GNUTAR / / 0 0 / 0 SIZE 3472863 real0m0.428s user 0m0.132s sys 0m0.292s "Wed Sep 11 15:59:02 2019: thd-0x5575c3fe1400: amandad: receive error: EOF on read from tf-p-ubu-amanda-00.xx.com" From: owner-amanda-us...@amanda.org On Behalf Of Robert Reilly 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 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:owner-amanda-us...@amanda.org> mailto:owner-amanda-us...@amanda.org>> On Behalf Of Robert Reilly Sent: Friday, September 6, 2019 10:55 AM To: amanda-users@amanda.org<mailto: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 Amanda 3.3.6 Immediately after starting the backup this is the state of the procs on the client backup 30608 1 0 11:36 ?00:00:00 /lib/systemd/systemd --user backup 30609 30608 0 11:36 ?00:00:00 (sd-pam) backup 30645 30606 0 11:36 ?00:00:00 sshd: backup@notty backup 30646 30645 0 11:36 ? 00:00:00 /usr/lib/amanda/amandad -auth=ssh backup 30648 30646 0 11:36 ?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/rreilly-edr/0fd11aff9cb4e157b614cf74c9b51ddb # Client Debug Log https://gist.github.com/rreilly-edr/37ea6314b19ecc96f31c3d846df0219d ## Thanks in advance.. Robert
RE: amandad defunct on client calcsize/sendsize hung
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 that. But I noticed you haven't defined "etimeout" (the time amanda waits for estimate results in seconds) in your amanda.conf. IIRC it defaults to something around 10 min. and that might be too short for the client. Does it help to set etimeout 3600 in amanda.conf? If yes, it's probably a good idea to define "dtimeout" as well and set it to twice or thrice the value of etimeout. Jens On 9/11/2019 2:30 PM, Robert Reilly wrote: > 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 > *On Behalf Of *Robert Reilly > *Sent:* Friday, 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 > > Amanda 3.3.6 > > > > Immediately after starting the backup this is the state of the procs > on the client > > backup 30608 1 0 11:36 ? 00:00:00 /lib/systemd/systemd > --user > > backup 30609 30608 0 11:36 ? 00:00:00 (sd-pam) > > backup 30645 30606 0 11:36 ? 00:00:00 sshd: backup@notty > > backup 30646 30645 0 11:36 ? 00:00:00 > /usr/lib/amanda/amandad -auth=ssh > > backup 30648 30646 0 11:36 ? 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/rreilly-edr/0fd11aff9cb4e157b614cf74c9b51ddb > > > > # > > > > Client Debug Log > > > > https://gist.github.com/rreilly-edr/37ea6314b19ecc96f31c3d846df0219d > > > > ## > > Thanks in advance.. > > Robert > > > > >
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 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 On Behalf Of Robert Reilly Sent: Friday, 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 Amanda 3.3.6 Immediately after starting the backup this is the state of the procs on the client backup 30608 1 0 11:36 ?00:00:00 /lib/systemd/systemd --user backup 30609 30608 0 11:36 ?00:00:00 (sd-pam) backup 30645 30606 0 11:36 ?00:00:00 sshd: backup@notty backup 30646 30645 0 11:36 ?00:00:00 /usr/lib/amanda/amandad -auth=ssh backup 30648 30646 0 11:36 ?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/rreilly-edr/0fd11aff9cb4e157b614cf74c9b51ddb # Client Debug Log https://gist.github.com/rreilly-edr/37ea6314b19ecc96f31c3d846df0219d ## Thanks in advance.. Robert
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 Amanda 3.3.6 Immediately after starting the backup this is the state of the procs on the client backup 30608 1 0 11:36 ?00:00:00 /lib/systemd/systemd --user backup 30609 30608 0 11:36 ?00:00:00 (sd-pam) backup 30645 30606 0 11:36 ?00:00:00 sshd: backup@notty backup 30646 30645 0 11:36 ?00:00:00 /usr/lib/amanda/amandad -auth=ssh backup 30648 30646 0 11:36 ?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/rreilly-edr/0fd11aff9cb4e157b614cf74c9b51ddb # Client Debug Log https://gist.github.com/rreilly-edr/37ea6314b19ecc96f31c3d846df0219d ## Thanks in advance.. Robert
Re: amanda 3.5.1 ignoring option amandad-path in amanda.conf
On Tue, Oct 30, 2018 at 07:08:31AM -0400, Nathan Stratton Treadway wrote:
> On Mon, Oct 29, 2018 at 19:01:45 +, Jose M Calhariz wrote:
> > To workaround this I am using a dumptype with:
> >
> > amandad-path "/usr/amanda/amandad"
> >
> > After some changes in disklist I think this option is not working.
> > That is strange. Is anyone using successfully this option? What
> > version of amanda are you using in the server? Anyone can check the
> > code?
>
> I haven't used this option myself, but from the amanda.conf man page
> entry for it the first question to ask is whether you are indeed using
> ssh authentication in this particular dumptype?
Yes, I am using only ssh authentication on this server.
>
> In a quick scan of the (upstream) git repo changelog I don't see any
> recent changes that obviously affect this option.
>
> If no one else with actual experience using this option chimes in, I
> could try to take a closer look at the code, but it would probably be
> easier to track down where in the source to look if you posted the full
> definition of the dumptype in question and also the exact text of the
> related messages you are finding in the log files
This is the debug dumptype, the comments are my try to pinpoint the
problem.
define dumptype special {
# Global definitions
# global
# lev-medium
# rhel
# From global
# comment "Global definitions"
# index yes
auth "ssh"
ssh_keys "/var/backups/.ssh/id_rsa_amdump"
# max-warnings 111
# comprate 99, 99
# compress best
exclude list optional ".amanda-exclude.list"
# From lev-medium
# program "APPLICATION"
# application "amgtar"
# priority medium
# maxpromoteday 6
# From rhel
client_username "amandabackup"
amandad-path "/usr/lib64/amanda/amandad"
}
The relevant error on amanda server, when I run "amcheck Daily -c
host.fqdn" is:
sh: /usr/lib/amanda/amandad
>
> Nathan
>
>
> Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region
> Ray Ontko & Co. - Software consulting services - http://www.ontko.com/
> GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239
> Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
>
>
Kind regards
Jose M Calhariz
--
--
Todo homem deveria ser incendiário até os 25 anos de idade, e bombeiro dali em
diante
--Alceu Amoroso Lima
signature.asc
Description: PGP signature
Re: amanda 3.5.1 ignoring option amandad-path in amanda.conf
On Mon, Oct 29, 2018 at 19:01:45 +, Jose M Calhariz wrote: > To workaround this I am using a dumptype with: > > amandad-path "/usr/amanda/amandad" > > After some changes in disklist I think this option is not working. > That is strange. Is anyone using successfully this option? What > version of amanda are you using in the server? Anyone can check the > code? I haven't used this option myself, but from the amanda.conf man page entry for it the first question to ask is whether you are indeed using ssh authentication in this particular dumptype? In a quick scan of the (upstream) git repo changelog I don't see any recent changes that obviously affect this option. If no one else with actual experience using this option chimes in, I could try to take a closer look at the code, but it would probably be easier to track down where in the source to look if you posted the full definition of the dumptype in question and also the exact text of the related messages you are finding in the log files Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
amanda 3.5.1 ignoring option amandad-path in amanda.conf
Hi, I am using the latest amanda 3.5.1 in Debian stretch and I want to do backup of other Linux systems, in this case CentOS. The amandad daemon in Debian packages is located in /usr/lib/amanda/amandad but in CentOS rpms is located in /usr/lib64/amanda/amandad. To workaround this I am using a dumptype with: amandad-path "/usr/amanda/amandad" After some changes in disklist I think this option is not working. That is strange. Is anyone using successfully this option? What version of amanda are you using in the server? Anyone can check the code? Kind regards Jose M Calhariz -- -- Eu quero ficar rica, mas não quero fazer o que é preciso para ficar rica --Gertrude Stein signature.asc Description: PGP signature
Re: how to change the amandad server (3.4.3) listening service port?
On Wed, 29 Mar 2017 14:45:18 -0400 Jean-Louis Martineau wrote: > It is xinetd that is listening, so it must be changed there: > In the xinetd file: >service 11080 >... Or set the 3.3.9 instance to use ssh. It is a bit more work, but will allow you to get rid of xinetd entirely and make your installation just a bit more secure. -- The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized. -- U.S. Const. Amendment IV Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB
Re: how to change the amandad server (3.4.3) listening service port?
* Jean-Louis Martineau [20170329 14:47]: > On 29/03/17 02:34 PM, Jean-Francois Malouin wrote: > > Hi, > > > > For whatever reasons I'm stuck for a little while with an amanda server > > with 2 different installations (one is community version 3.4.3 and the > > other is a zmanda enterprise edition running 3.3.9). I'd like to have > > them running concurrently and listening to different tcp ports under > > xinetd until one of them (the 3.4.3) can be disposed of -- a few weeks I > > guess until all the client DLEs are moved over. > > Both are running bsdtcp auth. > > > > How can I have one instance of amanda running on the default amanda > > service port 10080/tcp (the 3.3.9 server) and the other one (the 3.4.3 > > server) some other port? The 3.4.3 server is backing up only one client > > running 3.3.0. I assume that for this lone client I can set the option > > 'client-port [ int | string ]' in its dumptype but how do I make the > > server listen to some other port than the default amanda port 10080? Say > > 11080. Which configure/compile options do I have to set while > > recompiling the 3.4.3 server? Any hints? > > It is xinetd that is listening, so it must be changed there: > In the xinetd file: >service 11080 >... Of course! I'll give it a try. Such a simple answer for a convoluted question! Thanks Jean-Louis! jf > Jean-Louis
Re: how to change the amandad server (3.4.3) listening service port?
On 29/03/17 02:34 PM, Jean-Francois Malouin wrote: > Hi, > > For whatever reasons I'm stuck for a little while with an amanda server > with 2 different installations (one is community version 3.4.3 and the > other is a zmanda enterprise edition running 3.3.9). I'd like to have > them running concurrently and listening to different tcp ports under > xinetd until one of them (the 3.4.3) can be disposed of -- a few weeks I > guess until all the client DLEs are moved over. > Both are running bsdtcp auth. > > How can I have one instance of amanda running on the default amanda > service port 10080/tcp (the 3.3.9 server) and the other one (the 3.4.3 > server) some other port? The 3.4.3 server is backing up only one client > running 3.3.0. I assume that for this lone client I can set the option > 'client-port [ int | string ]' in its dumptype but how do I make the > server listen to some other port than the default amanda port 10080? Say > 11080. Which configure/compile options do I have to set while > recompiling the 3.4.3 server? Any hints? It is xinetd that is listening, so it must be changed there: In the xinetd file: service 11080 ... Jean-Louis This message is the property of CARBONITE, INC. and may contain confidential or privileged information. If this message has been delivered to you by mistake, then do not copy or deliver this message to anyone. Instead, destroy it and notify me by reply e-mail
how to change the amandad server (3.4.3) listening service port?
Hi, For whatever reasons I'm stuck for a little while with an amanda server with 2 different installations (one is community version 3.4.3 and the other is a zmanda enterprise edition running 3.3.9). I'd like to have them running concurrently and listening to different tcp ports under xinetd until one of them (the 3.4.3) can be disposed of -- a few weeks I guess until all the client DLEs are moved over. Both are running bsdtcp auth. How can I have one instance of amanda running on the default amanda service port 10080/tcp (the 3.3.9 server) and the other one (the 3.4.3 server) some other port? The 3.4.3 server is backing up only one client running 3.3.0. I assume that for this lone client I can set the option 'client-port [ int | string ]' in its dumptype but how do I make the server listen to some other port than the default amanda port 10080? Say 11080. Which configure/compile options do I have to set while recompiling the 3.4.3 server? Any hints? Thanks! jf
Re: amandad running as the wrong user
Thanks for the detailed info. Given that 3.3.2 for Ubuntu was released recently I uninstalled the server,common and the client, installed 3.3.2 and everything now works as expected; no changes needed anywhere. Thanks Leo On 12/08/12 09:32, Nathan Stratton Treadway wrote: > On Mon, Aug 06, 2012 at 22:23:30 +1000, Subscriptions wrote: >> Hi have posted this in the forum too, but have had no replies >> >> I have now downgraded/installed 3.3.0 on Ubuntu 12.04 LTS since the >> problem has been fixed but am now getting the following error >> >> WARNING: ml.zudiewiener.com: selfcheck request failed: >> tcpm_recv_token: invalid size: "amandad: running as user >> \"amandabackup\" instead of \"backup\"\n" >> Client check: 1 host checked in 0.045 seconds. 1 problem found. >> >> >> Everything is set up to use amandabackup as the user (and this >> worked for months prior to upgrading to 12.04), so not sure why it >> expects the user to be 'backup' > Debian (and thus Ubuntu) have always used the "backup" user in their > standard Amanda packages. So if your system was in fact using > "amandabackup" before 12.04, then you must have installed Amanda some > other way back then (e.g. from source, or using the .deb file from > amanda.org). > > Note, though, that there are accounts in use on both the client and the > server; it's certainly possible that your Ubuntu system was using > "backup" as the account on the client side while your server has been > using "amandabackup" all along. > > However, regarding your current problem: it does appear that the > /etc/xinetd.d/amanda file included in the 12.04 amanda-common package > specifies "user=amandabackup" for some reason; I assume this is a bug in > the packaging. > > (If you do a > $ grep inetd /var/lib/dpkg/info/amanda-common.postinst > , you'll see that the setup command used for other-than-xinetd internet > "super-server" daemons is > update-inetd --add "amanda stream tcp nowait backup /usr/lib/amanda/amandad > amandad -auth=bsdtcp amdump amindexd amidxtaped" > ... i.e. it uses "backup" as the user.) > > So, if you haven't already done so, I think updating > /etc/xinetd.d/amanda so that the user= line uses "backup" should fix > your problem. > > Note that you probably don't need to edit the /etc/amandahosts file, > since that grants incoming permission to the account on the server side > (which presumably hasn't changed). > > Hope that helps. > > Nathan > > > Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region > Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ > GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 > Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
Re: amandad running as the wrong user
On Mon, Aug 06, 2012 at 22:23:30 +1000, Subscriptions wrote: > > Hi have posted this in the forum too, but have had no replies > > I have now downgraded/installed 3.3.0 on Ubuntu 12.04 LTS since the > problem has been fixed but am now getting the following error > > WARNING: ml.zudiewiener.com: selfcheck request failed: > tcpm_recv_token: invalid size: "amandad: running as user > \"amandabackup\" instead of \"backup\"\n" > Client check: 1 host checked in 0.045 seconds. 1 problem found. > > > Everything is set up to use amandabackup as the user (and this > worked for months prior to upgrading to 12.04), so not sure why it > expects the user to be 'backup' Debian (and thus Ubuntu) have always used the "backup" user in their standard Amanda packages. So if your system was in fact using "amandabackup" before 12.04, then you must have installed Amanda some other way back then (e.g. from source, or using the .deb file from amanda.org). Note, though, that there are accounts in use on both the client and the server; it's certainly possible that your Ubuntu system was using "backup" as the account on the client side while your server has been using "amandabackup" all along. However, regarding your current problem: it does appear that the /etc/xinetd.d/amanda file included in the 12.04 amanda-common package specifies "user=amandabackup" for some reason; I assume this is a bug in the packaging. (If you do a $ grep inetd /var/lib/dpkg/info/amanda-common.postinst , you'll see that the setup command used for other-than-xinetd internet "super-server" daemons is update-inetd --add "amanda stream tcp nowait backup /usr/lib/amanda/amandad amandad -auth=bsdtcp amdump amindexd amidxtaped" ... i.e. it uses "backup" as the user.) So, if you haven't already done so, I think updating /etc/xinetd.d/amanda so that the user= line uses "backup" should fix your problem. Note that you probably don't need to edit the /etc/amandahosts file, since that grants incoming permission to the account on the server side (which presumably hasn't changed). Hope that helps. Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
Re: amandad running as the wrong user
xinetd.d/amandaserver looks like
---
service amanda
{
disable = no
flags = IPv4
socket_type = stream
protocol= tcp
wait= no
user= amandabackup
group = disk
groups = yes
server = /usr/lib/amanda/amandad
server_args = -auth=bsdtcp amdump amindexd amidxtaped
}
amandahosts looks like
localhost root amindexd amidxtaped
localhost amandabackup amdump
localhost.localdomain root amindexd amidxtaped
localhost.localdomain amandabackup amdump
-
Note sure what you mean by
$amanda_local_account
Cheers,
On 07/08/12 01:01, Bryan Hodgson wrote:
> On Mon, Aug 06, 2012 at 10:23:30PM +1000, Subscriptions wrote:
>> Everything is set up to use amandabackup as the user (and this
>> worked for months prior to upgrading to 12.04), so not sure why it
>> expects the user to be 'backup'
>>
> Doesn't matter. Fix xinetd.d/amanda, ~$amanda_local_account/.amandahosts
> to permit it to run, and move on.
>
Re: amandad running as the wrong user
On Mon, Aug 06, 2012 at 10:23:30PM +1000, Subscriptions wrote: > > Hi have posted this in the forum too, but have had no replies > > I have now downgraded/installed 3.3.0 on Ubuntu 12.04 LTS since the > problem has been fixed but am now getting the following error > > WARNING: ml.zudiewiener.com: selfcheck request failed: > tcpm_recv_token: invalid size: "amandad: running as user > \"amandabackup\" instead of \"backup\"\n" > Client check: 1 host checked in 0.045 seconds. 1 problem found. > > > Everything is set up to use amandabackup as the user (and this > worked for months prior to upgrading to 12.04), so not sure why it > expects the user to be 'backup' Just a guess, perhaps the pre-built amanda package you are using was compiled with a default user of "backup". As a workaround, it might work to create a user named "backup" with the same uid, gid, and home dir as "amandabackup". Simplest way is to edit /etc/passwd and /etc/shadow. Duplicate the "amandabackup" lines in those files and delete the leading 6 characters of the new line. jl -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (609) 477-8330 (C)
amandad running as the wrong user
Hi have posted this in the forum too, but have had no replies I have now downgraded/installed 3.3.0 on Ubuntu 12.04 LTS since the problem has been fixed but am now getting the following error WARNING: ml.zudiewiener.com: selfcheck request failed: tcpm_recv_token: invalid size: "amandad: running as user \"amandabackup\" instead of \"backup\"\n" Client check: 1 host checked in 0.045 seconds. 1 problem found. Everything is set up to use amandabackup as the user (and this worked for months prior to upgrading to 12.04), so not sure why it expects the user to be 'backup' <https://forums.zmanda.com/editpost.php?p=14838&do=editpost><https://forums.zmanda.com/newreply.php?do=newreply&p=14838&noquote=1><https://forums.zmanda.com/newreply.php?do=newreply&p=14838>
Re: long running amandad on client
On Fri, Oct 8, 2010 at 1:07 PM, John Hein wrote: > I have a client with an amandad that has been running since Sep 23... .. > 2000 APPLICATION 36 > |;auth=BSD;compress-fast;index;exclude-file=.no-amanda-backup;exclude-file=.nobak;exclude-file=.noback;exclude-file=.nodump; I would avoid BSD auth if possible. It uses UDP, so there is a bit of a race where amandad must wait around long enough to catch any new packets, but must exit at some point. Currently, this timeout is set to 30 seconds, but there may be (or have been) a particular case in which amandad can get "stuck" waiting for a new packet. The file-descriptor leaking is still a problem - amandad is in awful shape, to be honest - but zombie collection has improved somewhat (with band-aids, not a fix, but..) Dustin -- Open Source Storage Engineer http://www.zmanda.com
long running amandad on client
I have a client with an amandad that has been running since Sep 23... backup 97592 0.0 0.1 26780 7016 ?? Ss 23Sep10 40:30.43 amandad Most of the backups on that client still work fine. But two DLEs fail nightly. On the server, you get: 1286525084.841860: chunker: getcmd: START 20101007210002 1286525084.841877: chunker: getcmd: PORT-WRITE 00-00195 /holding/20101007210002/someclient._somedle.0 someclient 9ffe7f /somedle 0 1970:1:1:0:0:0 51 2000 APPLICATION 36 |;auth=BSD;compress-fast;index;exclude-file=.no-amanda-backup;exclude-file=.nobak;exclude-file=.noback;exclude-file=.nodump; 1286525084.842069: chunker: stream_server opening socket with family 2 (requested family was 2) 1286525084.842086: chunker: try_socksize: receive buffer size is 65536 1286525084.844115: chunker: bind_portrange2: Try port 11017: Available - Success 1286525084.844135: chunker: stream_server: waiting for connection: 0.0.0.0.11017 1286525084.844142: chunker: putresult: 23 PORT 1286525084.847225: chunker: stream_accept: connection from 127.0.0.1.11002 1286525084.847233: chunker: try_socksize: receive buffer size is 65536 1286525264.872340: chunker: putresult: 10 FAILED 1286525264.872462: chunker: pid 18935 finish time Fri Oct 8 02:07:44 2010 The amandad log on the client shows nothing at the 1286525084 timestamp (yes, the hosts in questions have good time sync). It does show sendbackup entries after the 3 minute timeout on the server above (1286525264 timestamp). So the client amandad seems to just be slow in responding. It's not clear why this long running amandad is slow in responding for a couple DLEs, but it's definitely abnormal to have such a long running amandad to begin with. lsof shows lots of open file descriptors like so: amandad 97592 backup 609u PIPE 0xff01dccfa00016384 ->0xff01dccfa158 There may be a descriptor leak bug, but that's sort of unimportant since _usually_ amandad runs only briefly. The real question is: why is amandad not exiting? Has anyone seen this before? I plan to kill amandad on the client, but I'll leave it running for a bit longer in case there might be something that can be learned. Unfortunately, this is amanda-2.6.1p1 on the client, so interest in learning about this anomaly in that code is likely low.
Re: hard coded limit REP_TIMEOUT of 6hrs in amandad-src/amandad.c
Jean-Francois Malouin wrote: * Dustin J. Mitchell [20090908 13:08]: On Tue, Sep 8, 2009 at 12:03 PM, Jean-Francois Malouin wrote: Hmmm, more than a week now and no replies. So I'll attempt to fix it myself: just to be on the safe side, any adverse effect to just bump up REP_TIMEOUT to, say 10hrs? Sorry, I thought I replied, but what I meant to say was essentially: yes, that sounds like something to fix :) As long as the client will die if the TCP connection goes away, I would prefer to get rid of the timeout altogether. These "long enough" timeouts are really only relevant for UDP, where the OS doesn't notify us of a lost connection (since there is no connection). I'm reviving this thread as I got hit again last night on a server running 2.6.1p1 that I reinstalled with REP_TIMEOUT=(12*60*60) ie, 12hrs. I'm still getting 6hrs timeouts on some DLEs: planner: [disk /raid/nih, all estimate timed out] REP_TIMEOUT is a client timeout, It must be configured on the client. You can also use "estimate server", less precise estimate but a lot faster. Jean-Louis
Re: hard coded limit REP_TIMEOUT of 6hrs in amandad-src/amandad.c
On Sat, Sep 26, 2009 at 1:06 PM, Jean-Francois Malouin wrote: > exactly 6 hours after amanda started its run. > Is there a timeout on the client side as well? > Client is at 2.5.2p1. I think that the timeout is bidirectional. Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: hard coded limit REP_TIMEOUT of 6hrs in amandad-src/amandad.c
* Dustin J. Mitchell [20090908 13:08]: > On Tue, Sep 8, 2009 at 12:03 PM, Jean-Francois > Malouin wrote: > > Hmmm, more than a week now and no replies. > > So I'll attempt to fix it myself: just to be on the safe side, > > any adverse effect to just bump up REP_TIMEOUT to, say 10hrs? > > Sorry, I thought I replied, but what I meant to say was essentially: > yes, that sounds like something to fix :) > > As long as the client will die if the TCP connection goes away, I > would prefer to get rid of the timeout altogether. These "long > enough" timeouts are really only relevant for UDP, where the OS > doesn't notify us of a lost connection (since there is no connection). I'm reviving this thread as I got hit again last night on a server running 2.6.1p1 that I reinstalled with REP_TIMEOUT=(12*60*60) ie, 12hrs. I'm still getting 6hrs timeouts on some DLEs: planner: [disk /raid/nih, all estimate timed out] exactly 6 hours after amanda started its run. Is there a timeout on the client side as well? Client is at 2.5.2p1. regards, jf > > Dustin > > -- > Open Source Storage Engineer > http://www.zmanda.com
Re: hard coded limit REP_TIMEOUT of 6hrs in amandad-src/amandad.c
On Tue, Sep 8, 2009 at 12:03 PM, Jean-Francois Malouin wrote: > Hmmm, more than a week now and no replies. > So I'll attempt to fix it myself: just to be on the safe side, > any adverse effect to just bump up REP_TIMEOUT to, say 10hrs? Sorry, I thought I replied, but what I meant to say was essentially: yes, that sounds like something to fix :) As long as the client will die if the TCP connection goes away, I would prefer to get rid of the timeout altogether. These "long enough" timeouts are really only relevant for UDP, where the OS doesn't notify us of a lost connection (since there is no connection). Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: hard coded limit REP_TIMEOUT of 6hrs in amandad-src/amandad.c
* Jean-Francois Malouin [20090831 13:38]: > Hi, > > I was hitting this hard coded limit a couple years ago running > 2.5.2-20070523 and over the last month it started to show up again on > a client having a lot of big DLEs (20 or so for a total of 11TB). > Client is running 2.6.0p2 and server is at 2.6.1p1. Back then > Jean-Louis provided me with a patch that reseted the timeout after > each estimates but just perusing the source I see that amandad.c > has been extensively rewritten. Anyone cares to have a look at this? Hmmm, more than a week now and no replies. So I'll attempt to fix it myself: just to be on the safe side, any adverse effect to just bump up REP_TIMEOUT to, say 10hrs? jf
hard coded limit REP_TIMEOUT of 6hrs in amandad-src/amandad.c
Hi, I was hitting this hard coded limit a couple years ago running 2.5.2-20070523 and over the last month it started to show up again on a client having a lot of big DLEs (20 or so for a total of 11TB). Client is running 2.6.0p2 and server is at 2.6.1p1. Back then Jean-Louis provided me with a patch that reseted the timeout after each estimates but just perusing the source I see that amandad.c has been extensively rewritten. Anyone cares to have a look at this? thanks, jf -- <° >< Jean-François Malouin McConnell Brain Imaging Centre Systems/Network Administrator Montréal Neurological Institute 3801 Rue Université, Suite WB219 Montréal, Québec, H3A 2B4 Phone: 514-398-8924 Fax: 514-398-8948
Re: Error - tcpm_recv_token: invalid size: amandad:
Thanks Dustin! Turns out that there was a permissions problem with /var/lib/amanda - I had at first installed with the repos for Ubuntu, then uninstalled and used the packages from Zmanda - so just changed the permissions to amandabackup:disk and amcheck runs fine. On Wed, 2008-12-03 at 21:18 -0500, Dustin J. Mitchell wrote: > On Wed, Dec 3, 2008 at 5:32 PM, Matt Burkhardt <[EMAIL PROTECTED]> wrote: > > WARNING: 192.168.1.102: selfcheck request failed: tcpm_recv_token: invalid > > size: amandad: > > What do you see if you telnet to that IP on port 10080? > > Dustin > Matt Burkhardt, MSTM President Impari Systems, Inc. 502 Fairview Avenue Frederick, MD 21701 [EMAIL PROTECTED] www.imparisystems.com (301) 682-7901
Re: Error - tcpm_recv_token: invalid size: amandad:
On Wed, Dec 3, 2008 at 5:32 PM, Matt Burkhardt <[EMAIL PROTECTED]> wrote: > WARNING: 192.168.1.102: selfcheck request failed: tcpm_recv_token: invalid > size: amandad: What do you see if you telnet to that IP on port 10080? Dustin -- Storage Software Engineer http://www.zmanda.com
Re: amandad args in inetd.conf
[EMAIL PROTECTED] wrote at 13:09 -0400 on Sep 26, 2008: > Hmm, thanks for mentioning. If I condense down my browser window, > the text goes beyond the bounding box but I can still scroll over > to see the full line of text. Are you not getting the same? Exactly the same. I was wondering if there is a wiki markup directive to have the bounding box extend to the end of the text rather than the border of the window. > > And somehow between 2.5 & 2.6, the .amandahost docs in amanda(8) lost > > the docs for the 'service(s)' field. > > > > I'm seeing the following in 2.6.0p2's amanda(8): Woops. My fault... bad zgrep for the strings in the various flavors of amanda I have installed (man pages in the 2.6* flavors moved into /share/man instead of /man).
Re: amandad args in inetd.conf
From: "John Hein" <[EMAIL PROTECTED]> Sent: Wednesday, September 24, 2008 11:00pm > Paul Yeatman wrote at 16:59 -0700 on Sep 24, 2008: > > Online Amanda documentation for inetd.conf configuration for both > > server and client are found on the Amanda wiki site here > > > > server: > > > > > > http://wiki.zmanda.com/index.php/Configuring_bsd/bsdudp/bsdtcp_authentication#xinetd.2Finetd_configuration_file_changes > > Thanks. Perhaps someone should add this info to the man pages. > Agreed. I am thus working on having this included in the next release. > I wonder how one might go about fixing the wikimedia markup to > extend the bounding box in the 'inetd.conf' example (assuming > your browser window is not really wide). Hmm, thanks for mentioning. If I condense down my browser window, the text goes beyond the bounding box but I can still scroll over to see the full line of text. Are you not getting the same? > > And somehow between 2.5 & 2.6, the .amandahost docs in amanda(8) lost > the docs for the 'service(s)' field. > I'm seeing the following in 2.6.0p2's amanda(8): "The format of the .amandahosts file is: hostname [ username [ service ]*] If username is ommitted, it defaults to the user running amandad, i.e. the user listed in the inetd or xinetd configuration file. The service is a list of the service the client is authorized to execute: amdump, noop, selfcheck, sendsize, sendbackup, amindexd, amidxtaped. amdump is a shortcut for "noop selfcheck sendsize sendbackup" > > > client: > > http://wiki.zmanda.com/index.php/Quick_start#Configuring_inetd_on_the_client > Thanks again. No problem. Paul
Re: amandad args in inetd.conf
Paul Yeatman wrote at 16:59 -0700 on Sep 24, 2008: > Online Amanda documentation for inetd.conf configuration for both > server and client are found on the Amanda wiki site here > > server: > http://wiki.zmanda.com/index.php/Configuring_bsd/bsdudp/bsdtcp_authentication#xinetd.2Finetd_configuration_file_changes Thanks. Perhaps someone should add this info to the man pages. I wonder how one might go about fixing the wikimedia markup to extend the bounding box in the 'inetd.conf' example (assuming your browser window is not really wide). And somehow between 2.5 & 2.6, the .amandahost docs in amanda(8) lost the docs for the 'service(s)' field. > client: > http://wiki.zmanda.com/index.php/Quick_start#Configuring_inetd_on_the_client Thanks again.
Re: amandad args in inetd.conf
Online Amanda documentation for inetd.conf configuration for both server and client are found on the Amanda wiki site here server: http://wiki.zmanda.com/index.php/Configuring_bsd/bsdudp/bsdtcp_authentication#xinetd.2Finetd_configuration_file_changes client: http://wiki.zmanda.com/index.php/Quick_start#Configuring_inetd_on_the_client Paul
Re: amandad args in inetd.conf
Olivier Cherrier wrote at 18:46 -0400 on Sep 23, 2008: > On Tue, Sep 23, 2008 at 10:27:26AM -0600, [EMAIL PROTECTED] wrote: > > Where are the docs for what args need to be added to amandad in > > inetd.conf? > > > > I added amindexd and amidxtaped on the backup server in order to do > > amrecover, but then amcheck failed (needed noop, then selfcheck). > > Then amdump failed (needed sendsize, ...). > > I think you have to populate your ~amandauser/.amandahosts with > something like that (amandauser = operator for me) : > yourHost operatoramdump > > >From amanda(8): "amdump is a shortcut for "noop selfcheck sendsize > sendbackup" Ah... difference between amanda-2.5 and amanda-2.6. At least a documentation difference. 2.5.* seems to be missing that documentation in the context of inetd.conf and 2.6.* doesn't have that tidbit at all (in fact it doesn't seem to support the service entry in .amandahosts in the 2.6 man page). I'm not sure if that's an oversight or deliberate. I also wonder if that alias is valid in inetd.conf. > > I see the full list in amandad.c, and I think I understand why clients > > don't need the addition. It defaults to all services except amindexd > > and amidxtaped being active. But when you activate those two on the > > server, it seems it _de_activates the others. > > I myself configured inetd.conf like that: > $ grep amandad /etc/inetd.conf > amandadgram udp wait operator /usr/local/libexec/amanda/amandad > amandad amindexd amidxtaped So you don't backup your server? Or you use .amandahosts to specify the services that amandad can run on the server? I guess I don't see a big difference between editing .amandahosts vs. inetd.conf
Re: amandad args in inetd.conf
On Tue, Sep 23, 2008 at 10:27:26AM -0600, [EMAIL PROTECTED] wrote: > Where are the docs for what args need to be added to amandad in > inetd.conf? > > I added amindexd and amidxtaped on the backup server in order to do > amrecover, but then amcheck failed (needed noop, then selfcheck). > Then amdump failed (needed sendsize, ...). I think you have to populate your ~amandauser/.amandahosts with something like that (amandauser = operator for me) : yourHostoperatoramdump >From amanda(8): "amdump is a shortcut for "noop selfcheck sendsize sendbackup" > I see the full list in amandad.c, and I think I understand why clients > don't need the addition. It defaults to all services except amindexd > and amidxtaped being active. But when you activate those two on the > server, it seems it _de_activates the others. I myself configured inetd.conf like that: $ grep amandad /etc/inetd.conf amandadgram udp wait operator /usr/local/libexec/amanda/amandad amandad amindexd amidxtaped Later, -- Olivier Cherrier - Symacx.com mailto:[EMAIL PROTECTED]
amandad args in inetd.conf
Where are the docs for what args need to be added to amandad in inetd.conf? I added amindexd and amidxtaped on the backup server in order to do amrecover, but then amcheck failed (needed noop, then selfcheck). Then amdump failed (needed sendsize, ...). I see the full list in amandad.c, and I think I understand why clients don't need the addition. It defaults to all services except amindexd and amidxtaped being active. But when you activate those two on the server, it seems it _de_activates the others. I didn't see it in the docs in the tarball and the wiki search leaves a bit to be desired. Where is it documented for the non-source diving crowd? Also, why would anyone want noop, selfcheck, sendbackup, etc., disabled? Is it a use case that some people don't back up their backup servers? I've been using a 2.4.5 server for so long, I've missed some details.
amandad keeps dying on me...
Hi all, I'm using Debian/stable, amanda 2.5.1p1 (note 2.5.1, NOT 2.5.2). For some reason amandad keeps dying on me. I can't find any reason in any of my logs for this. Currently, I still have the following processes running: amanda2:/var/log/amanda/amandad# ps -ef |grep backup backup 25763 9089 0 05:31 pts/100:00:00 /bin/sh /usr/sbin/amdump offsite amanda2 backup 25772 25763 0 05:31 pts/100:00:00 /usr/lib/amanda/planner offsite amanda2 backup 25773 25763 0 05:31 pts/100:00:00 /usr/lib/amanda/driver offsite amanda2 backup 25774 25773 0 05:31 pts/100:00:00 taper offsite backup 25775 25773 0 05:31 pts/100:00:00 dumper0 offsite backup 25776 25773 0 05:31 pts/100:00:00 dumper1 offsite backup 25777 25773 0 05:31 pts/100:00:00 dumper2 offsite backup 25778 25773 0 05:31 pts/100:00:00 dumper3 offsite backup 25779 25773 0 05:31 pts/100:00:00 dumper4 offsite backup 25780 25773 0 05:31 pts/100:00:00 dumper5 offsite backup 25781 25773 0 05:31 pts/100:00:00 dumper6 offsite backup 25782 25773 0 05:31 pts/100:00:00 dumper7 offsite backup 25783 25773 0 05:31 pts/100:00:00 dumper8 offsite backup 25784 25773 0 05:31 pts/100:00:00 dumper9 offsite backup 25785 25773 0 05:31 pts/100:00:00 dumper10 offsite backup 25786 25773 0 05:31 pts/100:00:00 dumper11 offsite backup 25787 25773 0 05:31 pts/100:00:00 dumper12 offsite backup 25788 25773 0 05:31 pts/100:00:00 dumper13 offsite backup 25789 25773 0 05:31 pts/100:00:00 dumper14 offsite backup 25790 25773 0 05:31 pts/100:00:00 dumper15 offsite backup 25791 25774 0 05:31 pts/100:00:00 taper offsite backup 29382 29381 0 12:47 pts/300:00:00 -sh The client in question is 'amanda2', which is NFS mounting several file systems from an OnStor NFS server. amstatus reports: Using /var/log/amanda/offsite/amdump.1 from Wed Sep 5 05:31:03 EDT 2007 amanda2:/00g waiting to flush amanda2:/00g estimate done amanda2:/home02g waiting to flush amanda2:/home02g estimate done amanda2:/nfs00g waiting to flush amanda2:/nfs00g estimate done amanda2:/nfs/RT 1 39g waiting to flush amanda2:/nfs/RT 0 582g estimate done amanda2:/nfs/archive0 11g waiting to flush amanda2:/nfs/archive0 11g estimate done amanda2:/nfs/backups00g waiting to flush amanda2:/nfs/backups00g estimate done amanda2:/nfs/builds 15g waiting to flush amanda2:/nfs/builds 0 117g estimate done amanda2:/nfs/debian 0 22g waiting to flush amanda2:/nfs/debian 0 22g estimate done amanda2:/nfs/patent 01g waiting to flush amanda2:/nfs/patent 01g estimate done amanda2:/nfs/release0 236g estimate done amanda2:/nfs/software 0 24g estimate done amanda2:/nfs/system 0 10g estimate done amanda2:/nfs/user 00g estimate done amanda2:/nfs/user/ad0 74g partial estimate done amanda2:/nfs/user/assar getting estimate amanda2:/nfs/user/ehgetting estimate amanda2:/nfs/user/ilgetting estimate amanda2:/nfs/user/mpgetting estimate amanda2:/nfs/user/qtgetting estimate amanda2:/nfs/user/uzgetting estimate amanda2:/usr 00g waiting to flush amanda2:/usr 00g estimate done amanda2:/var 01g waiting to flush amanda2:/var 01g estimate done SUMMARY part real estimated size size partition : 33 estimated : 16 1085g flush : 1185g failed : 00g ( 0.00%) wait for dumping: 00g ( 0.00%) dumping to tape : 00g ( 0.00%) dumping : 0 0g 0g ( 0.00%) ( 0.00%) dumped : 0 0g 0g ( 0.00%) ( 0.00%) wait for writing: 0 0g 0g ( 0.00%) ( 0.00%) wait to flush : 1185g85g (100.00%) ( 0.00%) writing to tape : 0 0g 0g ( 0.00%) ( 0.00%) failed to tape : 0 0g 0g ( 0.00%) ( 0.00%) taped : 0 0g 0g ( 0.00%) ( 0.00%) 16 dumpers idle : not-idle taper idle network free kps: 1048576 holding space : 1700g (100.00%) 0 dumpers busy : 0:00:00 ( 0.00%) But there is no estimate being done. There is no tar process running, amandad is not runn
Re: amandad troubles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Glenn English wrote: Absolutely never mind. I'm getting way too old to play this game... FWIW, the problem this time was not looking into DNS enough. - -- Glenn English [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG2vHX04yQfZbbTLYRAl1WAJ9RB2OeJujsYf46r9nvaZYvCucfIgCgrh5w 3LjCby76F86Ut0H5lsdN83g= =bxn4 -END PGP SIGNATURE-
amandad troubles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Debian etch Linux, Amanda v 2.5.1p1 from a debian package. The 2 clients on the DMZ don't respond; on the LAN all is well. The amanda server is on the LAN, there's a pix between the LAN and the DMZ, and this install / configuration has worked in the past (or maybe I should say 'a configuration pretty close to this one'). Amcheck says they time out waiting for an ACK; tcpdump shows packets arriving at the DMZ client, but nothing leaving (on a working host, there are several packets going back and forth); tcpdump on the server sees many packets running around the LAN, some going to the DMZ, and nothing coming back; disabling the iptables packet filters on the server and the client makes no difference; an entry in the client's daemon log says amandad was contacted; .amandahosts is valid, DNS works both ways, a reverse lookup of the server IP gives exactly the same text as is in .amandahosts, and emptying the file has no effect; when I run amcheck on the server, ps on the client shows amandad running for 30 seconds or so, then stopping, same as it does on a working client; running amandad by hand as the amanda user does the same thing (nothing) on a working or non-working client; if I delete /tmp/amanda, the directory is re-created after an amcheck, but it's empty; nagios successfully checks tftp on the DMZ client with no problems, the pix can write its config file to it, and both the pix and the border router do ntp with the server on the DMZ, so I'm fairly certain about UDP through the pix; I can get to ftp on the DMZ client from the amanda server (also run by inetd and watched over by tcpwrappers); ps shows inetd is running; the modification dates for amandad, tcpd, and inetd are well in the past; reinstalling the amanda client does nothing; rebooting makes no difference; and the hosts on the DMZ are running the same kernel as on the LAN. If this sounds familiar, it is. I had a very similar problem 2 or 3 weeks ago, and that turned out to have happened because I didn't check inetd well enough. I don't think it's inetd this time. I've tried the suggestions I could find via google (and in the responses from the list last time). No joy. Since the LAN works and the DMZ doesn't, it's 'obviously' the pix between them. But there's lots of evidence of packets getting through the pix from the server to the client (and of amandad starting up there). If the pix were blocking the return, I'd expect tcpdump to show packets leaving the DMZ client. But it doesn't, and iptables doesn't see any either. It looks like amandad never tries to answer. Any thoughts? Is there such a thing as a talking amandad? Just thought of something, but tar's mod date is in 2006... - -- Glenn English [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG2gMw04yQfZbbTLYRAh5rAJ4uV4vR96S3d3B/q4kpPVdyRi/oYQCeKwGm PonC1MpFAe6ZYWQxsGrfq5k= =z1yC -END PGP SIGNATURE-
Does amrecvoer connect to amandad ?
Does amrecover make a connection to the port amandad is running on? I'm doing some debugging, and I see inetd seeing a connection to that port when I run amrecover. I thought it connected to the index server. -- I'm sorry, no one here has any intentions of helping you with anything. I am the manager of all of Customer Service."
Regarding the script file & c file for amandad
Hi, I need one clarification regarding the amandad script file. amandad.c file present in client-src directory,when built amandad executable file generated in .libs ; and when we do make install then this file is moving to /usr/local/libexec. There is one more script file for amandad is generated. Why this file is requrired? Is this file is requried to create? Please clarify. Thanks & Regards, Silpakala Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index
Re: amandad on client
On 2006-08-21 10:03, Natalia García Nebot wrote: Hi all! I have a doubt: Is it possible run a daemon for amanda (amandad) on client instead of inetd or xinetd? No, amandad relies on an external program to do that. In all the Unix-variants I know there is at least inetd or xinetd provided. Just keep the services that you don't want disabled to avoid opening security holes. (verify with "netstat --natu" to see what is opened before and after starting (x)inetd). -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
amandad on client
Hi all! I have a doubt: Is it possible run a daemon for amanda (amandad) on client instead of inetd or xinetd?
Re: Solaris 8 inetd killing amandad
On Wed, Jul 19, 2006 at 10:46:18AM -0600, Chris Cameron wrote: On Tue, 2006-07-18 at 17:36 -0700, Kevin Till wrote: what is the amanda entry in /etc/inet/inetd.conf? amanda dgram udp waitroot/opt/amanda/libexec/amandad amandad Tried to run amandad as root-user instead of Amanda? Or is this just for the test? If you have run once as root, some files are created as root, and when running later as the backup user, Amanda cannot write into them. The most obvious one is /tmp/amanda debug directory. Leaving you without a clue why not even the debug output is not there. Most people notice this only when on the Amanda server the amcheck fails. That why a lot of client config problems are handled here: (instead of under "amandad issues") http://wiki.zmanda.com/index.php/Amcheck:_selfcheck_request_failed -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Re: Solaris 8 inetd killing amandad
On Wed, Jul 19, 2006 at 10:46:18AM -0600, Chris Cameron wrote:
> On Tue, 2006-07-18 at 17:36 -0700, Kevin Till wrote:
> >
> > what is the amanda entry in /etc/inet/inetd.conf?
>
> amanda dgram udp waitroot /opt/amanda/libexec/amandad
> amandad
>
>
> > Try "truss /opt/amanda/libexec/amandad" and see if there is anything
> > obviously wrong.
>
> Only thing that doesn't look normal to me:
>
> open("/usr/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1", O_RDONLY) = 3
> mmap(0xFF23, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0)
> = 0xFF23
> close(3)= 0
> brk(0x00024098) = 0
> brk(0x00026098) = 0
> sysconfig(_CONFIG_STACK_PROT) = 7
> fcntl(0, F_GETFD, 0x) = 0
> fcntl(1, F_GETFD, 0x0001) = 0
> fcntl(2, F_GETFD, 0x0001) = 0
> close(3)Err#9 EBADF
> close(4)Err#9 EBADF
> close(5)Err#9 EBADF
> close(6)Err#9 EBADF
> close(7)Err#9 EBADF
>
>
> The close()'s go all the way to 1023. After that it goes on to writing
> its debug output to /tmp/amanda.
>
>
> I don't know what they mean, but could all those close()'s be the cause?
Shouldn't. Amanda knows what file descriptors it will need.
As a security measure, most amanda commands, at start-up,
close all file descriptors that will not be needed.
--
Jon H. LaBadie [EMAIL PROTECTED]
JG Computing
4455 Province Line Road(609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Solaris 8 inetd killing amandad
Hi Chris,
Chris Cameron wrote:
On Tue, 2006-07-18 at 17:36 -0700, Kevin Till wrote:
what is the amanda entry in /etc/inet/inetd.conf?
amanda dgram udp waitroot/opt/amanda/libexec/amandad
amandad
i would try to start amandad as "amanda" (or whatever user you have
amanda compiled for), not as root ;-)
When using truss, i would give it the -f option to trace also child
processes.
Peter
Try "truss /opt/amanda/libexec/amandad" and see if there is anything obviously
wrong.
Only thing that doesn't look normal to me:
open("/usr/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1", O_RDONLY) = 3
mmap(0xFF23, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0)
= 0xFF23
close(3)= 0
brk(0x00024098) = 0
brk(0x00026098) = 0
sysconfig(_CONFIG_STACK_PROT) = 7
fcntl(0, F_GETFD, 0x) = 0
fcntl(1, F_GETFD, 0x0001) = 0
fcntl(2, F_GETFD, 0x0001) = 0
close(3)Err#9 EBADF
close(4)Err#9 EBADF
close(5)Err#9 EBADF
close(6)Err#9 EBADF
close(7)Err#9 EBADF
The close()'s go all the way to 1023. After that it goes on to writing
its debug output to /tmp/amanda.
I don't know what they mean, but could all those close()'s be the cause?
Chris
Re: Solaris 8 inetd killing amandad
On Tue, 2006-07-18 at 17:36 -0700, Kevin Till wrote:
>
> what is the amanda entry in /etc/inet/inetd.conf?
amanda dgram udp waitroot/opt/amanda/libexec/amandad
amandad
> Try "truss /opt/amanda/libexec/amandad" and see if there is anything
> obviously wrong.
Only thing that doesn't look normal to me:
open("/usr/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1", O_RDONLY) = 3
mmap(0xFF23, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0)
= 0xFF23
close(3)= 0
brk(0x00024098) = 0
brk(0x00026098) = 0
sysconfig(_CONFIG_STACK_PROT) = 7
fcntl(0, F_GETFD, 0x) = 0
fcntl(1, F_GETFD, 0x0001) = 0
fcntl(2, F_GETFD, 0x0001) = 0
close(3)Err#9 EBADF
close(4)Err#9 EBADF
close(5)Err#9 EBADF
close(6)Err#9 EBADF
close(7)Err#9 EBADF
The close()'s go all the way to 1023. After that it goes on to writing
its debug output to /tmp/amanda.
I don't know what they mean, but could all those close()'s be the cause?
Chris
Re: Solaris 8 inetd killing amandad
Chris Cameron wrote: Have 2 working Solaris machines being backed up by Amanda. Trying to add a 3rd, I just copy the amanda directory from one client to the new client, same way I installed the other one. Made an Amanda user, group other, add amanda entries to services, and entry to inetd.conf When I run amcheck I see this in my messages log on the new server: Jul 18 16:00:12 app01 inetd[169]: [ID 858011 daemon.warning] /opt/amanda/libexec/amandad: Killed Jul 18 16:00:50 app01 last message repeated 38 times Jul 18 16:00:51 app01 inetd[169]: [ID 667328 daemon.error] amanda/udp server failing (looping), service terminated ldd on amandad doesn't show any missing libraries. I've recompiled Amanda on the new machine, same problem. Tried different users, same problem. Anybody know what I've done here? what is the amanda entry in /etc/inet/inetd.conf? Try "truss /opt/amanda/libexec/amandad" and see if there is anything obviously wrong. -- Thank you! Kevin Till Amanda documentation: http://wiki.zmanda.com Amanda forums:http://forums.zmanda.com
Solaris 8 inetd killing amandad
Have 2 working Solaris machines being backed up by Amanda. Trying to add a 3rd, I just copy the amanda directory from one client to the new client, same way I installed the other one. Made an Amanda user, group other, add amanda entries to services, and entry to inetd.conf When I run amcheck I see this in my messages log on the new server: Jul 18 16:00:12 app01 inetd[169]: [ID 858011 daemon.warning] /opt/amanda/libexec/amandad: Killed Jul 18 16:00:50 app01 last message repeated 38 times Jul 18 16:00:51 app01 inetd[169]: [ID 667328 daemon.error] amanda/udp server failing (looping), service terminated ldd on amandad doesn't show any missing libraries. I've recompiled Amanda on the new machine, same problem. Tried different users, same problem. Anybody know what I've done here? Chris
Re: chunker ,amandad
2006/7/12, silpa kala <[EMAIL PROTECTED]>: Hi,Please help me out in this problem.I seen the socket connection between the chunker andamandad. What is purpose of the socket?Actually I understood that backup data send by theamandad(client) and received by the dumper(server)through the data port. Is it true?How the dumper will send the backup data to thechunker?I understood that chunker is introduced in 2.5version for new features splitsize. Suppose if i didn't configure for this parameters, eventhoughchunker is playing as an important role. Why thedumper funda is moved to chunker.Taper is creating the Shared Memory. Why it isnecessary?Please clarify me these doubts. Thanks & Regards,SilpakalaSorry but you are using the wrong mailing list, pal. This is amanda USERS, not HACKERS. There is a mailing list devoted to amanda development.
Communication between the chunker and amandad
Hi, Please help me out in this problem. I seen the socket connection between the chunker and amandad. What is purpose of the socket? Actually I understood that backup data send by the amandad(client) and received by the dumper(server)through the data port. Is it true? How the dumper will send the backup data to the chunker? I understood that chunker is introduced in 2.5 version for new features splitsize. Suppose if i didn't configure for this parameters, eventhough chunker is playing as an important role. Why the dumper funda is moved to chunker. Taper is creating the Shared Memory. Why it is necessary? Please clarify me these doubts. Thanks & Regards, Silpakala __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
chunker ,amandad
Hi, Please help me out in this problem. I seen the socket connection between the chunker and amandad. What is purpose of the socket? Actually I understood that backup data send by the amandad(client) and received by the dumper(server)through the data port. Is it true? How the dumper will send the backup data to the chunker? I understood that chunker is introduced in 2.5 version for new features splitsize. Suppose if i didn't configure for this parameters, eventhough chunker is playing as an important role. Why the dumper funda is moved to chunker. Taper is creating the Shared Memory. Why it is necessary? Please clarify me these doubts. Thanks & Regards, Silpakala __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Please clarify the socket connection between the dumper and amandad
Hi, Please clarify the TCP socket connection between the dumper and amandad. Let me know which one is acting as a server and client. If we specify the entry in the DLE like this 222.222.222.222 /home root-tar. chunker: stream_accept: connection from 127.0.0.1.45601 dumper: stream_client: connected to 127.0.0.1.784 chunker: try_socksize: receive buffer size is 32768 dumper: stream_client: our side is 0.0.0.0.45601 dumper: try_socksize: send buffer size is 65536 dumper: bind_portrange2: trying port=778 dumper: dgram_bind: socket bound to 0.0.0.0.778 dumper: stream_client: connected to 192.61.224.88.778 dumper: stream_client: our side is 0.0.0.0.35926 dumper: try_socksize: send buffer size is 65536 dumper: try_socksize: receive buffer size is 65536 Why the chunker and dumper is using three IP addresses in the above log data? The dumper is creating the previlgied prot no like 778 for data and one for mesg and one for index. what is the other port no 35926. Why the chunker is trying to connect to the port no? chunker: try_socksize: receive buffer size is 65536 chunker: bind_portrange2: trying port=784 chunker: stream_server: waiting for connection: 0.0.0.0.784 driver: result time 4.778 from chunker0: PORT 784 Please clarify me the TCP communication between amandad, dumper and chunker processes ? I am totally confused, even debugging is also difficult. Thanks & Regards, Silpakala __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
dumper, chunker and amandad communication
Hi, I need some clarification on Amanda Internals. Driver will initiate the chunker process and driver will provide some information to the chunker process like name of the file for holding disk, hostname, level, datastamp etc., How the driver will send the information to the chunker? either through pipes ?I copied some lines from the amdump logfile. driver: send-cmd time 4.768 to chunker0: PORT-WRITE 00-1 /home/20060705194408/hostname._home_amanda-2.5.0p1-20060428_server-src.1 hostname feff9ffe07 /home/amanda-2.5.0p1-20060428/ server-src 1 2006:7:6:0:42:13 1048576 GNUTAR 6624 |;auth=BSD;no-record;index; chunker is trying to connect to one privileged port no. Driver will initiate the dumper process and driver will provide some information to dumper port no to connect(what chunker initiated for the particular port), hostname etc., driver: send-cmd time 4.778 to dumper0: PORT-DUMP 00-1 784 hostname feff9ffe07 /home/amanda-2.5.0p1-20060428/server-src NODEVICE 1 2006:7:6:0:42:13 GNUTAR |;auth=BSD;no-record;index; Is there any socket communication is required between the chunker and driver ? I got so much of confusion with the amdump.1 log file. The contents i am sending here from the log file chunker: stream_accept: connection from 127.0.0.1.45601 dumper: stream_client: connected to 127.0.0.1.784 chunker: try_socksize: receive buffer size is 32768 dumper: stream_client: our side is 0.0.0.0.45601 dumper: try_socksize: send buffer size is 65536 What is the significance of this. Please explain? Amandad log file is also having the information below: amandad: try_socksize: send buffer size is 65536 amandad: try_socksize: receive buffer size is 65536 I think the above two log information is interconnected, what kind of information is sending and receiving by dumper or chunker or amandad? I need these clarifications. Please help me out to understand these funda. Thanks & Regards, Silpakala __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Linux + ipv6 + inetd == non-working amandad (solution)
Hi all, I'm posting here for the benefit of the next person who runs into this problem: If amandad is running through inetd on a Linux system with the ipv6 kernel module loaded, it will try to talk to 0.0.0.0 instead of whoever's on the other side of port 10080. The fix is to either remove the module (unverified) or to run in e.g. xinetd instead (verified). A helpful individual on #amanda suggested that setting the inetd "service type" field to "tcp46" may also work. Here's the symptom in amandad.debug: amandad: time 0.000: dgram_send_addr: sendto(0.0.0.0.566) failed: Invalid argument amandad: time 0.003: sending REP packet: Amanda 2.4 REP HANDLE 001-A8850608 SEQ 1152114891 ERROR [addr 0.0.0.0: hostname lookup failed Hope this helps somebody in the future... -- Christopher DeMarco <[EMAIL PROTECTED]> Alephant Systems (http://alephant.net) PGP public key at http://pgp.alephant.net +1-412-708-9660
Re: amandad process defunct
Hi and thanks for your replies. See below for the log file contents (21.06.06). It also shows the version (which I used simply because Red Hat had those rpms available on their web site - I didn't want to add the 'complexity' of having to compile the source myself). In my stupidity I don't see anything glaringly obvious that can be wrong. Amanda is configured to use gnu-tar, and there's no hardware compression or encryption involved. I don't see why it should still show it's busy at 9am when the backup runs at 24:45 every morning, and only backs up about 100mb (this is just for testing purposes using virtual tapes). But this has happened twice now, and I simply don't know what to do or how to fix it without rebooting the test lab machine. I'm very new to Linux and Amanda has been making my head hurt, so please accept my apologies if I sound silly. # cat amandad.20060621004501.debug amandad: debug 1 pid 8021 ruid 33 euid 33: start at Wed Jun 21 00:45:01 2006 amandad: version 2.4.4p1 amandad: build: VERSION="Amanda-2.4.4p1" amandad: BUILT_DATE="Mon Jun 20 14:39:39 EDT 2005" amandad:BUILT_MACH="Linux porky.build.redhat.com 2.4.21-25.ELsmp #1 SMP Fri Nov 12 21:34:51 EST 2004 i686 i686 i386 GNU/Linux" amandad:CC="i386-redhat-linux-gcc" amandad:CONFIGURE_COMMAND="'./configure' '--host=i386-redhat-linux' '--build=i386-redhat-linux' '--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/lib/amanda' '--localstatedir=/var/lib' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--enable-shared' '--with-index-server=localhost' '--with-gnutar-listdir=/var/lib/amanda/gnutar-lists' '--with-smbclient=/usr/bin/smbclient' '--with-amandahosts' '--with-user=amanda' '--with-group=disk' '--with-tmpdir=/var/log/amanda' '--with-gnutar=/bin/tar'" amandad: paths: bindir="/usr/bin" sbindir="/usr/sbin" amandad:libexecdir="/usr/lib/amanda" mandir="/usr/share/man" amandad: AMANDA_TMPDIR="/var/log/amanda" amandad:AMANDA_DBGDIR="/var/log/amanda" CONFIG_DIR="/etc/amanda" amandad:DEV_PREFIX="/dev/" RDEV_PREFIX="/dev/r" amandad:DUMP="/sbin/dump" RESTORE="/sbin/restore" amandad:SAMBA_CLIENT="/usr/bin/smbclient" GNUTAR="/bin/tar" amandad:COMPRESS_PATH="/usr/bin/gzip" amandad: UNCOMPRESS_PATH="/usr/bin/gzip" MAILER="/usr/bin/Mail" amandad:listed_incr_dir="/var/lib/amanda/gnutar-lists" amandad: defs: DEFAULT_SERVER="localhost" DEFAULT_CONFIG="DailySet1" amandad:DEFAULT_TAPE_SERVER="localhost" amandad:DEFAULT_TAPE_DEVICE="/dev/null" HAVE_MMAP HAVE_SYSVSHM amandad: LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE amandad:AMANDA_DEBUG_DAYS=4 BSD_SECURITY USE_AMANDAHOSTS amandad:CLIENT_LOGIN="amanda" FORCE_USERID HAVE_GZIP amandad: COMPRESS_SUFFIX=".gz" COMPRESS_FAST_OPT="--fast" amandad:COMPRESS_BEST_OPT="--best" UNCOMPRESS_OPT="-dc" amandad: time 0.000: got packet: Amanda 2.4 REQ HANDLE 001-D8690608 SEQ 1150847102 SECURITY USER amanda SERVICE noop OPTIONS features=feff9ffe0f; amandad: time 0.000: sending ack: Amanda 2.4 ACK HANDLE 001-D8690608 SEQ 1150847102 amandad: time 0.005: bsd security: remote host hades.matrix-data.local user amanda local user amanda amandad: time 0.005: amandahosts security check passed amandad: time 0.005: running service "noop" amandad: time 0.005: sending REP packet: Amanda 2.4 REP HANDLE 001-D8690608 SEQ 1150847102 OPTIONS features=feff9ffe0f; amandad: time 0.021: got packet: Amanda 2.4 ACK HANDLE 001-D8690608 SEQ 1150847102 amandad: time 0.024: pid 8021 finish time Wed Jun 21 00:45:01 2006 -- View this message in context: http://www.nabble.com/amandad-process-defunct-t1825006.html#a4991274 Sent from the Amanda - Users forum at Nabble.com.
Re: amandad process defunct
Joe Donner (sent by Nabble.com) schreef: Hi, I'm running Amanda in a test lab, and every several days or so the backup job to virtual tape fails because a process called amandad becomes unresponsive on the backup client. When doing an amcheck from the Amanda server it tells me that amandad on the client is "busy". When having a look at the client with the ps command, it lists two diferent amandad processes, with one showing as being "defunct". I cannot kill this process, but when I kill the other amandad process I can get rid of both, but then have to reboot the client to get the backup job to work again. Do you know how I can avoid doing this reboot, or what may be going on here? Reboot is a pretty drastic remedy :-) When the amandad process is killed, doesn't xinetd listen on port 10080/udp again? Do you have any idea what is "failing"? Usually in the debug files in /tmp/amanda on the client there should be more clues about what is going on. The error "amandad" busy actually indicates to me that the amandad is still active on that client: that is the response you get from the first amandad when you want to start another dump or check. -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Re: amandad process defunct
Joe, Which version of Amanda are you using? Please take a look at the log files in /tmp/amanda/ on the client system. You might have an idea which process exited and was not "waited" for (look for timestamps in the logs). Are you using compression or client side encryption? Thanks, Paddy On 6/21/06, Joe Donner (sent by Nabble.com) <[EMAIL PROTECTED]> wrote: Hi, I'm running Amanda in a test lab, and every several days or so the backup job to virtual tape fails because a process called amandad becomes unresponsive on the backup client. When doing an amcheck from the Amanda server it tells me that amandad on the client is "busy". When having a look at the client with the ps command, it lists two diferent amandad processes, with one showing as being "defunct". I cannot kill this process, but when I kill the other amandad process I can get rid of both, but then have to reboot the client to get the backup job to work again. Do you know how I can avoid doing this reboot, or what may be going on here? I'd appreciate your help as I'm pretty new to Amanda and Linux, but have been asked to look into Amanda as an alternative backup solution for our 5 Linux servers. Thanks in advance! Joe -- View this message in context: http://www.nabble.com/amandad-process-defunct-t1825006.html#a4977961 Sent from the Amanda - Users forum at Nabble.com. -- Amanda documentation: http://wiki.zmanda.com Amanda forums: http://forums.zmanda.com
amandad process defunct
Hi, I'm running Amanda in a test lab, and every several days or so the backup job to virtual tape fails because a process called amandad becomes unresponsive on the backup client. When doing an amcheck from the Amanda server it tells me that amandad on the client is "busy". When having a look at the client with the ps command, it lists two diferent amandad processes, with one showing as being "defunct". I cannot kill this process, but when I kill the other amandad process I can get rid of both, but then have to reboot the client to get the backup job to work again. Do you know how I can avoid doing this reboot, or what may be going on here? I'd appreciate your help as I'm pretty new to Amanda and Linux, but have been asked to look into Amanda as an alternative backup solution for our 5 Linux servers. Thanks in advance! Joe -- View this message in context: http://www.nabble.com/amandad-process-defunct-t1825006.html#a4977961 Sent from the Amanda - Users forum at Nabble.com.
Re: (subject change) Possible to run scripts just before an amandad?
On 2006-06-01 15:18, Francis Galiegue wrote: In fact I'm not asking for such a fine grained setup. I'd be perfectly happy with only a way to have amandad run scripts before and after backing up only, whatever the number of DLEs. At least, that's my need: a wrapper over amandad, not gtar. For instance, you could have two directories /etc/amandad/before (note the "d") and /etc/amandad/after with scripts named 00stoporacle, 01stopmysql, whatever. I have seen people add this shellscript to crontab to run the amanda dumps: #!/bin/sh ssh [EMAIL PROTECTED] /usr/local/bin/stopdb amdump daily ssh [EMAIL PROTECTED] /usr/local/bin/startdb With an approriate set of private/public keys to avoid password prompts of course. But I agree in general that before/after scripts more built into amanda would be welcome. -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
(subject change) Possible to run scripts just before an amandad?
(sorry for the misformulation of my first mail, I really meant that amandad, not amdump, was to run scripts before/after backup) Le Jeudi 01 Juin 2006 14:46, Jon LaBadie a écrit : > > > > IMHO, I think this is a quite common problem. > > Moreover, a "tar wrapper" is not practical when there are several DLEs > > for the same host. > > Sure it is. Though the wrapper is quite customized then. > The wrapper can examine the arguments passed to tar to > determine which DLE is the target and whether it is for > estimate or dump purposes. In fact I'm not asking for such a fine grained setup. I'd be perfectly happy with only a way to have amandad run scripts before and after backing up only, whatever the number of DLEs. At least, that's my need: a wrapper over amandad, not gtar. For instance, you could have two directories /etc/amandad/before (note the "d") and /etc/amandad/after with scripts named 00stoporacle, 01stopmysql, whatever. -- Francis Galiegue, [EMAIL PROTECTED] One2team - 12bis rue de la Pierre Levée, 75011 PARIS - 0143381980
Re: 2.4.2p2 client, 2.4.4p3 server: timeout from amandad...
Le Mercredi 03 Mai 2006 16:39, Paul Bijnens a écrit : > On 2006-05-03 15:53, Francis Galiegue wrote: > > "... definitely not..." resembles to some famous last words... > But I could be wrong of course. The test above will prove that. I did the test but did not wait long enough :p It was indeed the problem. Now I see why this conntrack module was created in the first place... Problem solved. Thanks very much for the link! -- Francis Galiegue, [EMAIL PROTECTED] One2team - 12bis rue de la Pierre Levée, 75011 PARIS - 0143381980
Re: 2.4.2p2 client, 2.4.4p3 server: timeout from amandad...
On 2006-05-03 15:53, Francis Galiegue wrote: Le Mercredi 03 Mai 2006 14:48, vous avez écrit : On 2006-05-03 13:26, Francis Galiegue wrote: You could run tcpdump or ethereal on the server and client and verify if indeed the packet is arriving there and with the correct IP-number (considering the aliases for eth0 can have messed that up). Well, if it did, I wouldn't have been able to do "small" backups either, would I? Is there a firewall inbetween, or on one/both of the servers? You may need to increase the UDP-reply timeout on the firewall (or disable the firewall). I believe many firewalls timeout UDP packets after 180 seconds. There's a firewall on both. On the client machine, UDP/10080 is let in from the server machine only. On the server machine, UDP/10082 and 10083 are let in from the client only. As to the timeout, I don't see this as a problem since I have an iptables rules that catches "INVALID" packets (as per conntrack definition) and it captures nothing at all... You're missing the UDP/10080 from client to server... (after timeout it is not related or tracked with conntrack). Actually iptables is one that times out UDP packets after 180 seconds. That why the ip_conntrack_amanda kernel module has the option to set that larger with the master_timeout parameter. Did you try this simple manual test: Start on the Amanda client: $ nc -vv -u -l -p 10080 Next on the Amanda server: $ nc -vv -u theclient.example.com 10080 Type something on the server (you should see that text appear on the client). Type something on the client (we simulate the ACK that the clients sends for the firewall). Now wait 5 minutes and type something on the client again (the final results packet). Is it received on the server? If not, do you notice a log entry for an INVALID packet ? (Because port 10080 is probably already in use by (x)inetd, you probably have to disable amanda udp/10080 on the client temporarily.) There are other possibilities, solutions. See: http://wiki.zmanda.com/index.php/Amdump:_results_missing in amanda 2.4.2p2 the "calcsize" was not yet implemented (it did exist, but was experimental, I believe). if the server is 2.4.4xx then you can use "estimate server", even if the client is old. From what I've read on the zmanda wiki, estimate server uses data from the previous runs. But there's no previous run... BTW I've tried the nc stuff on the wiki page as well: it's definitely not a firewall problem. "... definitely not..." resembles to some famous last words... But I could be wrong of course. The test above will prove that. -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Re: 2.4.2p2 client, 2.4.4p3 server: timeout from amandad...
Le Mercredi 03 Mai 2006 15:53, vous avez écrit : > > There's a firewall on both. On the client machine, UDP/10080 is let in from > the server machine only. On the server machine, UDP/10082 and 10083 are let > in from the client only. As to the timeout, I don't see this as a problem > since I have an iptables rules that catches "INVALID" packets (as per > conntrack definition) and it captures nothing at all... > OK well, I stand corrected. The zmanda Wiki link did provide me with an insight. I did NOT have the ip_conntrack_amanda module inserted. As such, the UDP timeout was the default, ie 30 seconds, ie far from being enough. I've therefore inserted this module with master_timeout=3600, that should do it... -- Francis Galiegue, [EMAIL PROTECTED] One2team - 12bis rue de la Pierre Levée, 75011 PARIS - 0143381980
Re: 2.4.2p2 client, 2.4.4p3 server: timeout from amandad...
Le Mercredi 03 Mai 2006 14:48, vous avez écrit : > On 2006-05-03 13:26, Francis Galiegue wrote: > > You could run tcpdump or ethereal on the server and client and verify > if indeed the packet is arriving there and with the correct IP-number > (considering the aliases for eth0 can have messed that up). > Well, if it did, I wouldn't have been able to do "small" backups either, would I? > Is there a firewall inbetween, or on one/both of the servers? > You may need to increase the UDP-reply timeout on the firewall (or > disable the firewall). I believe many firewalls timeout UDP packets > after 180 seconds. > There's a firewall on both. On the client machine, UDP/10080 is let in from the server machine only. On the server machine, UDP/10082 and 10083 are let in from the client only. As to the timeout, I don't see this as a problem since I have an iptables rules that catches "INVALID" packets (as per conntrack definition) and it captures nothing at all... > There are other possibilities, solutions. See: > > http://wiki.zmanda.com/index.php/Amdump:_results_missing > > in amanda 2.4.2p2 the "calcsize" was not yet implemented (it did > exist, but was experimental, I believe). > if the server is 2.4.4xx then you can use "estimate server", even > if the client is old. > >From what I've read on the zmanda wiki, estimate server uses data from the previous runs. But there's no previous run... BTW I've tried the nc stuff on the wiki page as well: it's definitely not a firewall problem. -- Francis Galiegue, [EMAIL PROTECTED] One2team - 12bis rue de la Pierre Levée, 75011 PARIS - 0143381980
Re: 2.4.2p2 client, 2.4.4p3 server: timeout from amandad...
On 2006-05-03 13:26, Francis Galiegue wrote: The list of filesystems represent 24 Gb total (compressed with gzip). The problem is this: it works fine when I try and backup every directory but one of the two largest (which are resp. 8.4 Gb and 10 Gb uncompressed on disk), and fails when I try to include either of these because _amandad_, not amdump, times out. I get this in the amandad logfile: amandad: debug 1 pid 6636 ruid 33 euid 33 start time Wed May 3 12:15:04 2006 amandad: version 2.4.2p2 [...] amandad: waiting for ack: timeout, retrying amandad: dgram_recv: timeout after 10 seconds amandad: waiting for ack: timeout, giving up! amandad: pid 6636 finish time Wed May 3 12:20:06 2006 Reproducible at will: amandad always times out after 5 minutes. Meanwhile, amdump stays there waiting for... Well, I don't know, frankly, but I have to C-c it and amcleanup afterwards. What I've already done is increase the etimeout parameter on the server side: I put 1200 instead of the default value, 300. But that didn't help. Out of despair I even tried and changed this value in the old server config files, in case amandad would try and read them :p But no. You could run tcpdump or ethereal on the server and client and verify if indeed the packet is arriving there and with the correct IP-number (considering the aliases for eth0 can have messed that up). Is there a firewall inbetween, or on one/both of the servers? You may need to increase the UDP-reply timeout on the firewall (or disable the firewall). I believe many firewalls timeout UDP packets after 180 seconds. There are other possibilities, solutions. See: http://wiki.zmanda.com/index.php/Amdump:_results_missing in amanda 2.4.2p2 the "calcsize" was not yet implemented (it did exist, but was experimental, I believe). if the server is 2.4.4xx then you can use "estimate server", even if the client is old. It should also be noted that the client machine is such a mess that my predecessor of a sysadmin created 6 aliases for interface eth0... I had to bind amandad specifically to the address I wanted so that dumps could work in the first place. But I don't see this having an influence here, since smaller backups work perfectly... I'd appreciate any hint on this one! -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
2.4.2p2 client, 2.4.4p3 server: timeout from amandad...
Hello everyone,
I'm in the process of migrating a full backup configuration from one machine
to another. The problem with the old one is threefold:
- it's a mess, which happens to be our main internal LAN server,
- it's obsolete software wise,
- the DAT changer attached to it now has insufficient capacity.
Such a mess it is that I cannot afford to install a new Amanda version on it
and see if that would cure the problem - some dumps are left on the holding
disk but then I can copy them around.
So, the new machine has a brand new DAT72x6 HP changer (DAT24x6 on the old
one), I've copied the old Amanda configuration to the new one and adapted
some settings (tapetype, in essence). Now the configuration looks like this:
org "One2team"
mailto "[EMAIL PROTECTED]"
dumpuser "amanda"
inparallel 4
netusage 5000 Kbps
dumpcycle 0 days
runspercycle 1 days
tapecycle 2 tapes
bumpsize 20 Mb
bumpdays 1
bumpmult 4
etimeout 1200
runtapes 1
tpchanger "/usr/lib/amanda/chg-zd-mtx"
tapedev "/dev/nst0"
changerfile "changer.conf"
changerdev "/dev/sg1"
tapetype HP-DAT72
labelstr "^full-[0-9][0-9]*$"
holdingdisk hd1 {
comment "main holding disk"
directory "/var/lib/amanda/full/dumps"
use -1024 Mb
}
reserve 30
infofile "/var/lib/amanda/full/info"
logdir "/var/lib/amanda/full/logs"
indexdir "/var/lib/amanda/full/index"
define tapetype HP-DAT72 {
comment "Produced by tapetype prog (hardware compression off)"
length 37511 mbytes
filemark 625 kbytes
speed 1758 kps
}
The dump types are defined like this (relevant settings only AFAICS):
define dumptype global {
comment "Global definitions"
exclude "./tmp"
}
define dumptype root-tar {
global
program "GNUTAR"
comment "root partitions dumped with tar"
compress none
index
exclude list "/etc/amanda/exclude.gtar"
priority low
}
define dumptype comp-root-tar {
root-tar
comment "Root partitions with compression"
compress server fast
}
The list of filesystems represent 24 Gb total (compressed with gzip). The
problem is this: it works fine when I try and backup every directory but one
of the two largest (which are resp. 8.4 Gb and 10 Gb uncompressed on disk),
and fails when I try to include either of these because _amandad_, not
amdump, times out. I get this in the amandad logfile:
amandad: debug 1 pid 6636 ruid 33 euid 33 start time Wed May 3 12:15:04 2006
amandad: version 2.4.2p2
amandad: build: VERSION="Amanda-2.4.2p2"
[blah blah]
Amanda 2.4 REQ HANDLE 000-9006B109 SEQ 1146651283
SECURITY USER amanda
SERVICE sendsize
OPTIONS features=feff9ffe0f;maxdumps=1;hostname=crios.olympe.o2t;
GNUTAR /usr/local 0 1970:1:1:0:0:0 -1 exclude-file=./tmp
[more blah]
sending ack:
Amanda 2.4 ACK HANDLE 000-9006B109 SEQ 1146651283
bsd security: remote host circe.olympe.o2t user amanda local user amanda
amandahosts security check passed
amandad: running service "/usr/lib/amanda/sendsize"
amandad: sending REP packet:
Amanda 2.4 REP HANDLE 000-9006B109 SEQ 1146651283
OPTIONS maxdumps=1;
/etc 0 SIZE 5990
/var/named 0 SIZE 40
[goes on and reports the rest]
amandad: dgram_recv: timeout after 10 seconds
amandad: waiting for ack: timeout, retrying
amandad: dgram_recv: timeout after 10 seconds
amandad: waiting for ack: timeout, retrying
amandad: dgram_recv: timeout after 10 seconds
amandad: waiting for ack: timeout, retrying
amandad: dgram_recv: timeout after 10 seconds
amandad: waiting for ack: timeout, retrying
amandad: dgram_recv: timeout after 10 seconds
amandad: waiting for ack: timeout, giving up!
amandad: pid 6636 finish time Wed May 3 12:20:06 2006
Reproducible at will: amandad always times out after 5 minutes. Meanwhile,
amdump stays there waiting for... Well, I don't know, frankly, but I have to
C-c it and amcleanup afterwards.
What I've already done is increase the etimeout parameter on the server side:
I put 1200 instead of the default value, 300. But that didn't help. Out of
despair I even tried and changed this value in the old server config files,
in case amandad would try and read them :p But no.
It should also be noted that the client machine is such a mess that my
predecessor of a sysadmin created 6 aliases for interface eth0... I had to
bind amandad specifically to the address I wanted so that dumps could work in
the first place. But I don't see this having an influence here, since smaller
backups work perfectly...
I'd appreciate any hint on this one!
Thanks,
--
Francis Galiegue, [EMAIL PROTECTED]
One2team - 12bis rue de la Pierre Levée, 75011 PARIS - 0143381980
Re: amandad can't be started
Jon LaBadie wrote:
On Thu, Feb 23, 2006 at 04:34:19PM +0100, Patrick Mania wrote:
Dear group,
The problem is, that the amandad canŽt be started.
I execute $Prefix/libexec/amandad, this takes a while (30 secs) and breaks.
amandad is not intended to run continually nor to be run from the command line.
It starts as needed by {x}inetd and communicates over the network.
You are just seeing its timeout and exit when no one is talking to it
over the network.
Hi Jon,
thanks for your reply. I´ve just started the amandad manually because on
"amcheck" from the amanda server the result is "request timed out" for
this machine.
Greetings,
Patrick
Re: amandad can't be started
On Thu, Feb 23, 2006 at 04:34:19PM +0100, Patrick Mania wrote:
> Dear group,
>
>
>
> The problem is, that the amandad canŽt be started.
>
> I execute $Prefix/libexec/amandad, this takes a while (30 secs) and breaks.
>
>
amandad is not intended to run continually nor to be run from the command line.
It starts as needed by {x}inetd and communicates over the network.
You are just seeing its timeout and exit when no one is talking to it
over the network.
--
Jon H. LaBadie [EMAIL PROTECTED]
JG Computing
4455 Province Line Road(609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
amandad can't be started
Dear group, i´am trying to install the amanda client from the current version. I´ve configured it with user=amanda group=disk and client installation only The prefix is /usr/amanda. The problem is, that the amandad can´t be started. I execute $Prefix/libexec/amandad, this takes a while (30 secs) and breaks. The Logfile says: serv:/usr/amanda/libexec# cat /tmp/amanda/amandad.20060220015348.debug amandad: debug 1 pid 2500 ruid 1000 euid 1000: start at Mon Feb 20 01:53:48 2006 amandad: version 2.4.5p1 Building Infos amandad: time 29.992: dgram_recv: timeout after 30 seconds amandad: error receiving message: timeout amandad: time 29.993: error receiving message: timeout amandad: time 29.993: pid 2500 finish time Mon Feb 20 01:54:18 2006 This is my inetd.conf: serv:/usr/amanda# cat /etc/inetd.conf # /etc/inetd.conf: see inetd(8) for further informations. # # Internet server configuration database # # # Lines starting with "#:LABEL:" or "##" should not # be changed unless you know what you are doing! # # If you want to disable an entry so it isn't touched during # package updates just comment it out with a single '#' character. # # Packages should modify this file by using update-inetd(8) # # # #:INTERNAL: Internal services #echo stream tcp nowait root internal #echo dgram udp wait root internal #chargen stream tcp nowait root internal #chargen dgram udp wait root internal #discard stream tcp nowait root internal #discard dgram udp wait root internal #daytime stream tcp nowait root internal #daytime dgram udp wait root internal #time stream tcp nowait root internal #time dgram udp wait root internal #:STANDARD: These are standard services. #:BSD: Shell, login, exec and talk are BSD protocols. shell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind exec stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rexecd amanda dgram udp wait amanda /usr/amanda/libexec/amandad amandad The /etc/services file: hitchhiker:/usr/amanda/libexec# cat /etc/services | grep amanda amanda 10080/udp # Amanda backup services kamanda 10081/tcp # amanda backup services (Kerberos) kamanda 10081/udp amandaidx 10082/tcp # amanda backup services amidxtape 10083/tcp # amanda backup services The inetd seems to work: serv:/usr/amanda/libexec# netstat -a | grep amanda udp 0 0 *:amanda *:* The /etc/hosts.deny and /etc/hosts.allow files are empty. The Items in http://wiki.zmanda.com/index.php/Amcheck:_selfcheck_request_timed_out seems to be correct. Any suggestions? Greetings, Patrick
Re: amandad busy (solved)
f.y.i. The reboot of the client did indeed fix the problem without me having to change any of the timeout settings. I only refrained from doing this because my timeouts were more than high enough already and as the backup size hadn't suddenly changed, the backups should have worked with their current settings. Would love to know what the reboot does to sort the problem. Prior to the reboot I had killed off all the amanda owned processes but still the backups failed. The reboot suggestion from Gene sorted it however. Thank you for your input Gene and amanda-users! Shabs.Gene Heskett <[EMAIL PROTECTED]> wrote: On Friday 27 January 2006 06:05, shoaib r wrote:>I've had backups working for over 2 mon! ths now.>> A system reboot started daily failures on the remote machine:>> Report says:> ==> FAILURE AND STRANGE DUMP SUMMARY:> planner: ERROR host1NAK : amandad busy> host01 /export RESULTS MISSING>> etc...>> amandad.debug says:> > amandad: time 30.009: dgram_recv: timeout after 30 seconds>amandad: error receiving message: timeout>amandad: time 30.010: error receiving message: timeout>> No changes made to amanda.conf or any other configuration.>> The tape server is backing its filesystems up sucessfully. However> the one and only remote server is not.>> Does anyone have any ideas?>> Thank youISTR I've had that happen once or twice, not recently, because a zombie was left on the client, possibly due to a timeout error. A reboot of the client should fix that. And you ! might add a bit to the timeout values in your amanda.conf just for insurance. An additional 25% should be enough, if indeed that was the cause.-- Cheers, GenePeople having trouble with vz bouncing email to me should add the word'online' between the 'verizon', and the dot which bypasses vz'sstupid bounce rules. I do use spamassassin too. :-)Yahoo.com and AOL/TW attorneys please note, additions to the abovemessage by Gene Heskett are:Copyright 2006 by Maurice Eugene Heskett, all rights reserved. Yahoo! Photos NEW, now offering a quality print service from just 8p a photo.
Re: amandad busy
sorry I should have mentioned, I'm using Solaris 9. My etimeout is set to -8000 (which has been ok for months) but i still think its way to much. I didnt change it as this is the error i'm getting now: FAILURE AND STRANGE DUMP SUMMARY: planner: ERROR Estimate timeout from host01 host01 /u01 lev 0 FAILED [disk /u01, all estimate timed out] host01 /opt lev 0 FAILED [disk /opt, all estimate timed out] host01 /var lev 0 FAILED [disk /var, all estimate timed out] host01 /usr lev 0 FAILED [disk /usr, all estimate timed out] host01 / lev 0 FAILED [disk /, all estimate timed out] host01 /export lev 0 FAILED 20060124 [too many dumper retry] Will schedule a reboot in and see how it goes. The above error would indicate to me that the etimeout isn't high eno! ugh but its already at 8000secs (133mins)!! Dont understand that. Thanks for input so far guys. shabs Salvatore Enrico Indiogine <[EMAIL PROTECTED]> wrote: 2006/1/27, shoaib r <[EMAIL PROTECTED]>:> I've had backups working for over 2 months now.> A system reboot started daily failures on the remote machine:> The tape server is backing its filesystems up sucessfully. However the one> and only remote server is not.>> Does anyone have any ideas?> Thank youJust a shot in the dark, but a reboot will usually boot the newlyinstalled kernel if you have something like yum update set onautomatic.Check e.g. /var/log/messages, uname -r, dmesgI am assuming you run Linux and use yum. Simila! r things could havehappened with automatic apt-get upgrade.--Enrico IndiogineParasol LaboratoryTexas A&M University[EMAIL PROTECTED][EMAIL PROTECTED]979-845-3937 To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre.
Re: amandad busy
2006/1/27, shoaib r <[EMAIL PROTECTED]>: > I've had backups working for over 2 months now. > A system reboot started daily failures on the remote machine: > The tape server is backing its filesystems up sucessfully. However the one > and only remote server is not. > > Does anyone have any ideas? > Thank you Just a shot in the dark, but a reboot will usually boot the newly installed kernel if you have something like yum update set on automatic. Check e.g. /var/log/messages, uname -r, dmesg I am assuming you run Linux and use yum. Similar things could have happened with automatic apt-get upgrade. -- Enrico Indiogine Parasol Laboratory Texas A&M University [EMAIL PROTECTED] [EMAIL PROTECTED] 979-845-3937
Re: amandad busy
On Friday 27 January 2006 06:05, shoaib r wrote: >I've had backups working for over 2 months now. > > A system reboot started daily failures on the remote machine: > > Report says: > == >FAILURE AND STRANGE DUMP SUMMARY: > planner: ERROR host1NAK : amandad busy > host01 /export RESULTS MISSING > > etc... > > amandad.debug says: > > amandad: time 30.009: dgram_recv: timeout after 30 seconds >amandad: error receiving message: timeout >amandad: time 30.010: error receiving message: timeout > > No changes made to amanda.conf or any other configuration. > > The tape server is backing its filesystems up sucessfully. However > the one and only remote server is not. > > Does anyone have any ideas? > > Thank you ISTR I've had that happen once or twice, not recently, because a zombie was left on the client, possibly due to a timeout error. A reboot of the client should fix that. And you might add a bit to the timeout values in your amanda.conf just for insurance. An additional 25% should be enough, if indeed that was the cause. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
amandad busy
I've had backups working for over 2 months now. A system reboot started daily failures on the remote machine: Report says: ==FAILURE AND STRANGE DUMP SUMMARY: planner: ERROR host1NAK : amandad busy host01 /export RESULTS MISSING etc... amandad.debug says: ==== amandad: time 30.009: dgram_recv: timeout after 30 secondsamandad: error receiving message: timeoutamandad: time 30.010: error receiving message: timeout No changes made to amanda.conf or any other configuration. The tape server is backing its filesystems up sucessfully. However the one and only remote server is not. Does anyone have any ideas? Thank you Yahoo! Photos NEW, now offering a quality print service from just 8p a photo.
amandad still running/ RESULTS MISSING
I am having a problem with amanda whereby some of the dumps (DLE's on the amanda server itself) are showing as RESULTS MISSING in the logs. There is an amandad process which is still running after quite a long time (24 hours) and which has a defunct child process: backup3318 0.0 0.1 3044 1076 ?SMay26 0:00 amandad backup3320 0.0 0.0 00 ?ZMay26 0:00 [amandad ] I googled the RESULTS MISSING error and checked that the appropriate files have SUID set and that the entries in inetd are right (they have not been changed). The only change that I have made in the last couple days is to add a DLE on a remote system (which already had other DLE's being backed up). Anyone have a clue for me? TIA, Vicki
Amcheck issue - i run amandad as amanda user and here is the blurb
amandad: debug 1 pid 2758 ruid 2003 euid 2003: start at Wed May 18 17:13:31 2005 amandad: version 2.4.4p2 amandad: build: VERSION="Amanda-2.4.4p2" amandad:BUILT_DATE="Wed Jun 30 23:45:53 UTC 2004" amandad:BUILT_MACH="Linux eisenstein 2.6.5 #1 Thu Nov 14 12:14:04 UTC 2002 i686 i686 i386 GNU/Linux" amandad:CC="gcc" amandad:CONFIGURE_COMMAND="'./configure' '--mandir=/usr/share/man' '--prefix=/usr' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--libdir=/usr/lib' '--libexecdir=/usr/lib/amanda' '--localstatedir=/var/lib' '--with-index-server=localhost' '--with-gnutar-listdir=/var/lib/amanda/gnutar-lists' '--with-smbclient=/usr/bin/smbclient' '--with-amandahosts' '--with-user=amanda' '--with-group=disk' '--with-gnutar=/bin/tar' '--disable-libtool' '--disable-shared' '--disable-static'" amandad: paths: bindir="/usr/bin" sbindir="/usr/sbin" amandad: libexecdir="/usr/lib/amanda" mandir="/usr/share/man" amandad:AMANDA_TMPDIR="/tmp/amanda" AMANDA_DBGDIR="/tmp/amanda" amandad:CONFIG_DIR="/etc/amanda" DEV_PREFIX="/dev/" amandad: RDEV_PREFIX="/dev/r" DUMP="/sbin/dump" amandad:RESTORE="/sbin/restore" VDUMP=UNDEF VRESTORE=UNDEF amandad:XFSDUMP=UNDEF XFSRESTORE=UNDEF VXDUMP=UNDEF VXRESTORE=UNDEF amandad:SAMBA_CLIENT="/usr/bin/smbclient" GNUTAR="/bin/tar" amandad:COMPRESS_PATH="/usr/bin/gzip" amandad:UNCOMPRESS_PATH="/usr/bin/gzip" LPRCMD="/usr/bin/lpr" amandad:MAILER="/usr/bin/Mail" amandad:listed_incr_dir="/var/lib/amanda/gnutar-lists" amandad: defs: DEFAULT_SERVER="localhost" DEFAULT_CONFIG="DailySet1" amandad: DEFAULT_TAPE_SERVER="localhost" amandad:DEFAULT_TAPE_DEVICE="/dev/null" HAVE_MMAP HAVE_SYSVSHM amandad:LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE amandad:AMANDA_DEBUG_DAYS=4 BSD_SECURITY USE_AMANDAHOSTS amandad:CLIENT_LOGIN="amanda" FORCE_USERID HAVE_GZIP amandad:COMPRESS_SUFFIX=".gz" COMPRESS_FAST_OPT="--fast" amandad:COMPRESS_BEST_OPT="--best" UNCOMPRESS_OPT="-dc" amandad: time 29.995: dgram_recv: timeout after 30 seconds amandad: error receiving message: timeout amandad: time 29.995: error receiving message: timeout amandad: time 29.995: pid 2758 finish time Wed May 18 17:14:01 2005 ~ Has anyone any idea and is there info realting to my Client hist always been down!.
Re: localhost amandad busy
Hi, Bert, on Freitag, 25. März 2005 at 14:52 you wrote to amanda-users: Bpb> WARNING: Usage of fully qualified hostname recommended for Client localhost. Bpb> WARNING: Usage of fully qualified hostname recommended for Client localhost. Bpb> ERROR: NAK localhost: amandad busy Bpb> Client check: 3 hosts checked in 20.062 seconds, 1 problem found Bpb> Googling around didn't solve too much, The mentioned WARNING is pretty new to AMANDA. Bpb> Simple solution : do what Amanda asks you to do : don't use localhost :-) Bpb> So, after changing the localhost for smb-shares to Bpb> goscinny; the problem went away. Good. And if someone finds this thread after googling now, he may also refer to http://www.amanda.org/docs/topten.html#id2519209 for more on this good old topic. -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
localhost amandad busy
Not a question, just something I encountered today; I had a disklist containing some local directories and some nt server's directories; something like this : # Local directory goscinny /home server-compress-low goscinny /root server-compress goscinny /var server-compress # NT-machine localhost //CMS/CMS server-compress-low localhost //CMS/wwwroot server-compress-low localhost //CMS/IIS_NR server-compress-low When doing an amcheck, I got this error : WARNING: Usage of fully qualified hostname recommended for Client localhost. WARNING: Usage of fully qualified hostname recommended for Client localhost. ERROR: NAK localhost: amandad busy Client check: 3 hosts checked in 20.062 seconds, 1 problem found I should also mention that xinetd was being used on site, not inetd. Googling around didn't solve too much, some suggestions about changing the amanda configuration in xinetd.d directory. But all to no avail. Simple solution : do what Amanda asks you to do : don't use localhost :-) So, after changing the localhost for smb-shares to goscinny; the problem went away. Regards, Bert De Ridder PeopleWare NV - Head Office Cdt.Weynsstraat 85 B-2660 Hoboken Tel: +32 3 448.33.38 Fax: +32 3 448.32.66 PeopleWare NV - Branch Office Geel Kleinhoefstraat 5 B-2440 Geel Tel: +32 14 57.00.90 Fax: +32 14 58.13.25 http://www.peopleware.be http://www.mobileware.be
Re: How to run amandad without inetd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Newman said the following on 1/9/2005 1:49 PM: |>I configured all host the same using amanda as user name and group name at |>compile time. I checked and rechecked. When I run amcheck on 11.00 server |>to connect to itself there is a debug entry in /tmp/amanda for amcheck but |>nothing for amandad. If I do this on a working machine there is an entry |>in /tmp/amanda for amcheck and anandad. | | | Yes, after running amcheck you should see at least four files in | /tmp/amanda: two from amandad, one from amcheck, and one from selfcheck. | | It sounds like this is indeed some problem with amandad not running on the | 11.00 box. From the packets below, it doesn't look like amandad ever gets | invoked. | Could this be a problem with ~ a) a firewall blocking access to (one of) the port(s) on Linux i would say iptables. I have no idea what the equivalent on HP-UX is... ~ b) tcp-wrappers not allowing access (even to localhost) (check /etc/hosts.* files)? just a guess -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFB4MpQRWbA1HjQuHERAo/KAJwL9qkMFhQRcIHkIrzEXCpQARayLQCgt5lT 021rdjxhMxp2CYBP6qWBTkU= =rTrU -END PGP SIGNATURE-
