Mantis - amanda
Viewing Issue Advanced Details
4254 regular use major always 2010-02-03 15:00 2010-06-14 14:48
amyrrich  
darin  
normal  
closed  
unable to reproduce  
none    
none  
0004254: svc:/network/amanda/udp:default always enters maintenance state when amcheck or amservice is run
Upgraded from amanda-2.4.4p4,REV=2005.08.05-SunOS5.8-sparc-CSW.pkg to
manda-2.6.1,REV=2009.05.28_rev=p1-SunOS5.8-sparc-CSW.pkg on the amanda server, and amcheck to the local host stopped functioning. Whenever amcheck or amservice is run, it always transitions the amanda/udp service into a maintenance state. amcheck and amservice continue to function fine with clients that have not been upgraded. Downgrading back to amanda-2.4.4p4,REV=2005.08.05-SunOS5.8-sparc-CSW.pkg fixed the issue.
# grep Amanda /etc/services
amanda 10080/tcp # Amanda
amanda 10080/udp # Amanda
amandaidx 10082/tcp # Amanda index server
amidxtape 10083/tcp # Amanda tape server


# inetadm -l svc:/network/amanda/udp:default
SCOPE NAME=VALUE
         name="amanda"
         endpoint_type="dgram"
         proto="udp"
         isrpc=FALSE
         wait=TRUE
         exec="/opt/csw/libexec/amanda/amandad"
         user="amanda"
default bind_addr=""
default bind_fail_max=-1
default bind_fail_interval=-1
default max_con_rate=-1
default max_copies=-1
default con_rate_offline=-1
default failrate_cnt=40
default failrate_interval=60
default inherit_env=TRUE
default tcp_trace=FALSE
default tcp_wrappers=FALSE
default connection_backlog=10

# netstat -a|grep am
      *.amanda Idle
      *.amidxtape *.* 0 0 49152 0 LISTEN
      *.amandaidx *.* 0 0 49152 0 LISTEN


Error from /var/adm/messages:

Feb 2 23:36:15 hostname inetd[8366]: [ID 702911 daemon.error] Instance svc:/network/amanda/udp:default has exceeded its configured failure rate, transitioning to maintenance

# less amservice.20100202233608.debug
1265171768.963163: amservice: pid 8458 ruid 666 euid 666 version 2.6.1p1: start at Tue Feb 2 23:36:08 2010
1265171768.968367: amservice: security_getdriver(name=bsdudp) returns ff297ac4
1265171768.968652: amservice: security_handleinit(handle=31790, driver=ff297ac4 (BSDUDP))
1265171768.974518: amservice: dgram_bind: setting up a socket with family 2
1265171768.977046: amservice: bind_portrange2: Try port 578: Available - Success
1265171768.977619: amservice: dgram_bind: socket 4 bound to 0.0.0.0.578
1265171768.979469: amservice: dgram_send_addr(addr=317b0, dgram=ff2cdce4)
1265171768.979632: amservice: (sockaddr_in *)317b0 = { 2, 10080, 192.168.1.3 }
1265171768.979755: amservice: dgram_send_addr: ff2cdce4->socket = 4
1265171779.121385: amservice: dgram_send_addr(addr=317b0, dgram=ff2cdce4)
1265171779.121558: amservice: (sockaddr_in *)317b0 = { 2, 10080, 192.168.1.3 }
1265171779.121677: amservice: dgram_send_addr: ff2cdce4->socket = 4
1265171789.122973: amservice: dgram_send_addr(addr=317b0, dgram=ff2cdce4)
1265171789.123146: amservice: (sockaddr_in *)317b0 = { 2, 10080, 192.168.1.3 }
1265171789.123268: amservice: dgram_send_addr: ff2cdce4->socket = 4
1265171799.124027: amservice: security_seterror(handle=31790, driver=ff297ac4 (BSDUDP) error=timeout waiting for ACK)
1265171799.124649: amservice: security_close(handle=31790, driver=ff297ac4 (BSDUDP))
1265171799.125059: amservice: pid 8458 finish time Tue Feb 2 23:36:39 2010


Issue History
2010-02-03 15:00 amyrrich New Issue
2010-02-03 15:10 bonivart Issue Monitored: bonivart
2010-05-11 15:46 bonivart Status new => assigned
2010-05-11 15:46 bonivart Assigned To => darin
2010-05-11 16:41 darin Note Added: 0007920
2010-05-11 17:19 darin Note Added: 0007921
2010-05-11 19:17 darin Note Added: 0007923
2010-06-14 14:48 darin Note Added: 0008015
2010-06-14 14:48 darin Status assigned => closed
2010-06-14 14:48 darin Resolution open => unable to reproduce
2010-07-10 22:52 dustin Issue Monitored: dustin

Notes
(0007920)
darin   
2010-05-11 16:41   
I have never run across this issue but I'll take a look at it and try to recreate the issue.

What is the amservice command you are running?
What is the amcheck command you are running?
(0007921)
darin   
2010-05-11 17:19   
Are your clients still running version 2.4.4p4?
(0007923)
darin   
2010-05-11 19:17   
I've performed the update from 2.4.4p4 to 2.6.1p1 and the only issue I've run into was that the inetd service locations changed and I needed to run 'inetconv -f' to forcefully update the service profile.

Please contact me directly at darin@opencsw.org so I can gather additional details about your setup.
(0008015)
darin   
2010-06-14 14:48   
Unable to reproduce. I've requested that the reported contact me which they've failed to do.