Good question. The amanda server on this site is running Ubuntu and so 3.3.6 is the latest available amanda in the distro repos. Since most other *nix boxes are running Ubuntu, doing my own build is a bit of a chore. Not to mention I am quite unfamiliar with cooking up deb packages. So the curve is a bit steep which is what keeps me from going to the latest amanda version.
That said, I did upgrade the amanda server to Ubuntu 16 in order to move from amanda 3.3.3 to 3.3.6 thinking that would correct this problem based on the post I mentioned previously. On Fri, Jul 29, 2016 at 10:21 AM, Ochressandro Rettinger < [email protected]> wrote: > Asking as a newb who genuinely doesn't know: How hard is it to > upgrade Amanda? > > If this is a 3.3.6 era bug, maybe upgrading all of your nodes to > 3.3.9 would solve your problem? > > -Sandro > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Chris Nighswonger > Sent: Thursday, July 28, 2016 12:08 PM > To: [email protected] > Cc: Jean-Louis Martineau <[email protected]> > Subject: Re: amcheck failing when checking multiple clients > > Maybe John-Louis can jump in here since these are symptoms of a bug which > was supposed to have been fixed in 3.3.6.... > > > http://www.backupcentral.com/phpBB2/two-way-mirrors-of-external-mailing-lists-3/amanda-20/amdumps-failing-and-some-amchecks-as-well-124340/ > > Summary of where things stand on this install: > > Server version 3.3.6 > Client versions 3.3.3, 3.3.6 > > auth = bsdtcp > > The issue: > > 1. amcheck fails on a subset of clients when run against multiple clients > (regardless of client version) with "selfcheck request failed: > error sending REQ: write error to: Broken pipe" > 2. amcheck does not fail on all clients, but fails on the same subset of > clients each time. > 3. amcheck does not fail when run against any single client, including > those in the subset which does fail when run against multiple clients. > 4. amservice fails when run against any member of that subset of clients > which fails amcheck with "Request failed: Permission denied" > 5. dumps run fine during the nightly backups for all clients, including > those members of that amcheck failing subset. > > Misc. notes: > > 1. When amcheck fails on a client, the client contains no debug log. > 2. The server amcheck debug log reflects the same issue mentioned above > "Broken pipe" > 3. From the prospective of a failing client: tcpdump shows an exchange of > about 40 packets with the client when amcheck is run against a single > client and succeeds 4. From the same prospective, tcpdump shows an exchange > of about 68 packets with the client when amcheck is run against multiple > clients and fails 5. All file perms have been checked and are correct on > both server and client 6. backup user settings are correct on server and > client 7. amandahosts is properly configured 8. xinetd configuration is > correct on both server and client 9. forward and reverse DNS works > correctly for the client > > I wonder if this might be a variation of the bug mentioned by JLM in the > above referenced thread? > > Thanks for everyone's help here. > > > On Thu, Jul 28, 2016 at 10:15 AM, Ochressandro Rettinger < > [email protected]> wrote: > > In the second chunk of log messages, it looks like for some > reason the BSDTCP connection is closing early. Unfortunately, I can't help > you out with that, as I'm set up to use ssh. > > > > Good luck! > > > > -Sandro > > > > -----Original Message----- > > From: Chris Nighswonger [mailto:[email protected]] > > Sent: Thursday, July 28, 2016 7:10 AM > > To: [email protected] > > Cc: Ochressandro Rettinger <[email protected]> > > Subject: Re: amcheck failing when checking multiple clients > > > > Here are some potentially relevant lines form the log: > > > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > > conn_read_callback 1 3 > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: > > tcpm_recv_token: read 47 bytes from 1 > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > > conn_read_callback: tcpm_recv_token returned 47 Wed Jul 27 13:37:41 > 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > > stream_read_callback: handle 1 > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > > stream_read_callback: it was for us > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > > stream_read_callback: read 47 bytes from scriptor:1 Wed Jul 27 13:37:41 > 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > > recvpkt_callback: 47 > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > > cancelling recvpkt for scriptor > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > > conn_read_cancel: decremented ev_read_refcnt to 0 for scriptor Wed Jul > 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > > conn_read_cancel: releasing event handler for scriptor Wed Jul 27 > 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > > parse_pkt: parsing buffer of 47 bytes > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > > parse_pkt: REP (1): "OPTIONS features=ffffffff9efefbffffffffff3f; > > " > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > > received REP packet (1) from scriptor, contains: > > > > "OPTIONS features=ffffffff9efefbffffffffff3f; > > " > > > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > > stream_sendpkt: enter > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > > stream_sendpkt: ACK (3) pkt_t (len 0) contains: > > > > "" > > > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > > stream_write: writing 2 bytes to scriptor:1 3 Wed Jul 27 13:37:41 2016: > thd-0x55f48f90bc00: amcheck-clients: > > tcpm_send_token: write 2 bytes to handle 1 Wed Jul 27 13:37:41 2016: > thd-0x55f48f90bc00: amcheck-clients: > > security_getdriver(name=bsdtcp) returns 0x7ffbb3e53100 Wed Jul 27 > 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: bsdtcp: > > bsdtcp_connect: scriptor > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: > > security_handleinit(handle=0x55f48f9d63d0, driver=0x7ffbb3e53100 > > (BSDTCP)) > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: > > security_streaminit(stream=0x55f48fa102d0, driver=0x7ffbb3e53100 > > (BSDTCP)) > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: > > sec_tcp_conn_get: scriptor > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: > > sec_tcp_conn_get: exists, refcnt to scriptor is now 3 Wed Jul 27 > 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > > stream_client: connected to stream 13 > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: > > security_close(handle=0x55f48f91e760, driver=0x7ffbb3e53100 (BSDTCP)) > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > > closing handle to scriptor > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > > cancelling recvpkt for scriptor > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: > > security_stream_close(0x55f48f9b0e50) > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > > tcpma_stream_close: closing stream 1 > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > > stream_write: writing 0 bytes to scriptor:1 3 Wed Jul 27 13:37:41 2016: > thd-0x55f48f90bc00: amcheck-clients: > > tcpm_send_token: write 0 bytes to handle 1 Wed Jul 27 13:37:41 2016: > thd-0x55f48f90bc00: amcheck-clients: > > security_stream_seterr(0x55f48f9b0e50, write error to: Broken pipe) Wed > Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: > > sec_tcp_conn_put: decrementing refcnt for scriptor to 2 Wed Jul 27 > 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > > after callback stream_read_callback > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > > conn_read_callback: event_wakeup return 1 > > > > > > > > On Wed, Jul 27, 2016 at 3:19 PM, Ochressandro Rettinger < > [email protected]> wrote: > >> Does the amcheck.XXX.debug or amcheck-device.XXX.debug file > have anything useful in it? > >> > >> -Sandro > >> > >> -----Original Message----- > >> From: [email protected] > >> [mailto:[email protected]] On Behalf Of Chris Nighswonger > >> Sent: Wednesday, July 27, 2016 12:20 PM > >> To: [email protected] > >> Subject: Re: amcheck failing when checking multiple clients > >> > >> No takers? > >> > >> Additionally, on the failing client side an amcheck log is created > >> *only* if amcheck is run against that client. When amcheck is run > against the entire job (all clients) no amcheck log is created on the > clients that fail. > >> > >> > >> > >> On Tue, Jul 26, 2016 at 9:09 AM, Chris Nighswonger < > [email protected]> wrote: > >>> tcpdump shows that there is no (zero) data flow between the server > >>> and failed clients when running amcheck on multiple clients at once. > >>> Data does flow when checking a single client. > >>> > >>> This only started about a month ago. Maybe this is a bug? > >>> > >>> On Mon, Jul 25, 2016 at 4:16 PM, Chris Nighswonger > >>> <[email protected]> wrote: > >>>> Here is some snips of output illustrating the problem: > >>>> > >>>> > >>>> backup@scriptor: amcheck -c campus scriptor > >>>> > >>>> Amanda Backup Client Hosts Check > >>>> -------------------------------- > >>>> Client check: 1 host checked in 2.372 seconds. 0 problems found. > >>>> > >>>> (brought to you by Amanda 3.3.6) > >>>> backup@scriptor: amcheck -c campus masada > >>>> > >>>> Amanda Backup Client Hosts Check > >>>> -------------------------------- > >>>> Client check: 1 host checked in 2.074 seconds. 0 problems found. > >>>> > >>>> (brought to you by Amanda 3.3.6) > >>>> backup@scriptor: amcheck -c campus > >>>> > >>>> Amanda Backup Client Hosts Check > >>>> -------------------------------- > >>>> WARNING: scriptor: selfcheck request failed: error sending REQ: > >>>> write error to: Broken pipe > >>>> WARNING: masada: selfcheck request failed: error sending REQ: write > >>>> error to: Broken pipe > >>>> > >>>> > >>>> Server version is 3.3.6 > >>>> Client version on scriptor is 3.3.6 and on masada is 3.3.3 > >>>> > >>>> When the backup runs over night, the same error appears on these > clients. > >>>> > >>>> Any thoughts on what might be going on here? > >>>> > >>>> Kind regards, > >>>> Chris > >> > > >
