Anonymous | Login | 2024-05-04 10:48 CEST |
Main | My View | View Issues |
Viewing Issue Advanced Details [ Jump to Notes ] | [ View Simple ] [ Issue History ] [ Print ] | ||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||
0004254 | [amanda] regular use | major | always | 2010-02-03 15:00 | 2010-06-14 14:48 | ||
Reporter | amyrrich | View Status | public | ||||
Assigned To | darin | ||||||
Priority | normal | Resolution | unable to reproduce | Platform | |||
Status | closed | OS | |||||
Projection | none | OS Version | |||||
ETA | none | Product Build | |||||
Summary | 0004254: svc:/network/amanda/udp:default always enters maintenance state when amcheck or amservice is run | ||||||
Description |
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. |
||||||
Steps To Reproduce | |||||||
Additional Information |
# 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 |
||||||
Tags | No tags attached. | ||||||
Attached Files | |||||||
|
Notes | |
(0007920) darin (reporter) 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 (reporter) 2010-05-11 17:19 |
Are your clients still running version 2.4.4p4? |
(0007923) darin (reporter) 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 (reporter) 2010-06-14 14:48 |
Unable to reproduce. I've requested that the reported contact me which they've failed to do. |
Copyright © 2000 - 2008 Mantis Group |