Jon,
You can remove the faullty 4 lines.
3.4 can do multiple backup in parallel.
Instead of using amdump_client/amdumpd, you should use ambackup/ambackupd.
amdump_client/amdumpd is the old protocol and is kept only for
compatibility with 3.3
Jean-Louis
On 08/03/17 02:19 PM, Jon LaBadie wrote:
> On Sun, Mar 05, 2017 at 12:33:28AM -0500, Jon LaBadie wrote:
>> Anyone ever seen a "Amanda Busy" message before?
>>
>> Got a little further with amdump_client. Now the
>> two remote clients (Fedora 24&25, Fedora binaries 3.4.2)
>> are connecting to the server (CentOS7.3, Zmanda binaries
>> 3.4.2). Of the three amdump_client commands, "list" is
>> working but "check" and "dump" are giving the message
>> "Busy, Amanda is busy, try again later".
>>
>> There are no amanda processes running, neither on the
>> server nor either of the clients.
>>
>> jl
> I found the source of the "BUSY" message. It is line 172
> of /usr/libexec/amanda/amdumpd:
>
> if (-f "$logdir/log" || -f "$logdir/amdump" || -f "$logdir/amflush") {
> $self->sendctlline("BUSY Amanda is busy, retry later");
> return;
> }
>
> amdumpd looks for 3 files that each indicate some type of
> activity by amanda. The offender in my case is "log". This
> is a symbolic link created as part of a normal amdump run
> to point to the time-stamped "log" file.
>
> Unfortunately "log" is not removed at the end of the amanda
> activity and amdumpd fails. "amcleanup -p" removes "log"
> and I can get one step further.
>
> Jon
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.