Well I am none the wiser but this situation has again fixed itself.
I suppose I shouldn't complain as at least all the servers are working again.
But I really don't like faults like this that come and go with no idea as to
what is causing the issue.
Glen.
Here is the tail end of the amandad debug log on the failing server. It
appears that maybe a sub-process is aborting ?
<
OPTIONS features=9efefbff3f;
>
Tue Mar 31 00:45:13 2015: thd-0x7f2223302e00: amandad: tcpm_send_token: data is
still flowing
Tue Mar 31 00:45:23 2015:
log shows clearly that
authentication has succeeded.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Glen Eustace,
GodZone Internet Services, a division of AGRE Enterprises Ltd.,
P.O. Box 8020, Palmerston North, New Zealand 4446
Ph +64 6 357 8168 Fax +64 6 357 8165
> On 21/02/2015, at 3:42 pm, Glen Eustace wrote:
>
> My amanda installation has been working flawlessly for many years. It is
> currently amend 3.3.6 running on Fedora 20.
> In the last couple of weeks, one client has started to fail with the infamous
> error
>
> Am
andad: sec_tcp_conn_put:
decrementing refcnt for agree-10.xxx.xxx.nz to 0
Sat Feb 21 14:48:14 2015: thd-0x7f264e41ce00: amandad: sec_tcp_conn_put:
closing connection to agree-10.xxx.xxx.nz
Sat Feb 21 14:48:14 2015: thd-0x7f264e41ce00: amandad: pid 29987 finish time
Sat Feb 21 14:48:14 2015
--
=-=
My solution was to download the SRC rpm and edit the patch file
tar-1.17-xattrs.patch
I simply commented out the two warnings and rebuilt the rpm and used the
result to update my servers.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Glen and Rosanne Eustace
God
I am getting thousands of messages similiar to the following in the
amanda summary report
? gtar: ./var/lib/ntp: Warning: Cannot fgetfilecon: No data available
I think this is something to do with SELinux. How does one provide additional arguments to gtar ? I am hoping that adding
--no-xat
After much head scratching I finally managed to find a way to debug this.
The problem was that another application ( still can't work out how ),
changed the ownership and permissions on /dev/null,
this prevented selfcheck and sendbackup from running as they didn't have
sufficient priveleges.
I am still struggling to debug this one.
The server that succeeds has the following in its amandad.debug, when
amcheck is run
<
SERVICE noop
OPTIONS features=feff9ffe07;
>
amandad: time 0.002: creating new service: noop
OPTIONS features=feff9ffe07;
amandad: time 0.009:
This is getting more and more weird. I just build a 3rd server, same
distro. It would also appear to work fine. I removed amanda from the
failing server and re-installed. Didn't seem to make any difference.
The two new ones both seem happy with calcsize, but the original still
isn't :-(
--
I have just built another server, same specs as the one that is failing.
I have rebooted both. The new one when I do amcheck -c produces a
selcheck.exclude log in /var/log/amanda and a selfcheck.debug in the
client directory.
The server that is failing produces neither. All I got was
Amanda
Generally this kind of intermittent failure is caused by timeouts that
are too low. Try increasing the timeouts.
http://wiki.zmanda.com/index.php/Results_missing
I have had a look at this page, good stuff but unfortunately not too
helpful at this stage.
When things fail, I don't even get
A couple of weeks back, I added a new server to our network. It is
running fedora 8 - amanda-2.5.2p1, the backups failed from day 1. Then
mysteriously for about 4 days they worked and now they don't again.
amcheck says everything is fine, but the dump fails.
The only message I get is
agree-
On Sun, 03 Feb 2002 15:19, John R. Jackson wrote:
> >I was more than a little dismayed today to find that all of the backups I
> >have been doing are not recoverable. ...
>
> Yeah, that kind of thing can really put an end to a perfectly good day.
> Could you post some examples of what you tried
On Thu, 07 Feb 2002 11:23, John R. Jackson wrote:
> You don't, but any chance, have "record no" set someplace in your dumptype
> ("amadmin disklist | grep record")?
Bingo!!
There was 'record no' in the global section. I don't recall putting it there
but what the hey!! Will see what happens
On Wed, 06 Feb 2002 10:11, Dietmar Goldbeck wrote:
> tar --version
1.13.17
> and check if you have a runtar debug file (usually under /tmp/amanda)
gtar: version 2.4.2p2
running: /bin/gtar: gtar --create --file - --directory / --one-file-system
--listed-incremental /usr/local/var/amanda/gnutar-
This is probably a super dumb question but ...
I have just noticed ( never really looked very hard before ), that amanda
doesn't seem to be doing incrementals with tar. A Level 0 and the subsequent
Level 1 dumps are the same size ( give or take a few bytes ). How does one
make tar do incremen
It would seem that we have some kind of conflict with hardware and software
compression. If both are on, the backups can not be restored. I have managed
to turn off software compression and that seems to cure the problem but would
prefer to do software and not hardware.
I have tried turning o
Well, last nights test, using not HW compression and software compression
only was interesting. amverify failed miserably again on all the tape files,
an example of the output.
GDZN07 (agree-10._usr_local.20020204.1):
amrestore: WARNING: not at start of tape, file numbers will be offset
amresto
OK, the results of last nights trial.
With no software compression, the tape wrote fine.
amverify worked fine, or at least appeared to.
I have just attempted to recover a file using amrecover and that has seemed
to work, so far so good.
Tonight, I am going to try to turn off the HW compressio
On Sun, 03 Feb 2002 17:01, John R. Jackson wrote:
> I know it's of no help now, but have you run amverify? Mostly I'm
> interested in hearing if it catches the problem (it certainly won't fix
> anything for you now). If it doesn't report the error, we need to work
> on that.
I ran amverify on
On Sun, 03 Feb 2002 15:19, John R. Jackson wrote:
> >I was more than a little dismayed today to find that all of the backups I
> >have been doing are not recoverable. ...
>
> Yeah, that kind of thing can really put an end to a perfectly good day.
> Could you post some examples of what you tried
I was more than a little dismayed today to find that all of the backups I
have been doing are not recoverable. I needed to restore some files today,
and at this stage it looks like I am out of options.
The client is i386 rh7.1 running the amanda-2.4.2p2 clients as installed from
the rh RPM.
I have just recently built a new backup server, CCG CY-10e jukebox, Exb-8505
on a SPARC20 running RH6.2, amanda-2.4.2pl2
Backups seem to have been working fine, but I just went to restore a file and
got the following. The file is obviously in the index as amrecover found it
and let me select
I posted this at the time this list appeared broken and hence wonder whether
anyone actually received it.
I am relatively new to Amanda, though I have has it running quite
satisfactorilly with a single DAT drive backing up 4 servers for nearly 5
months.
I have recently acquired a Sparc20, stand
25 matches
Mail list logo
