Try changing this and restarting xinetd. See if the problem continues.
- service amandaidx
- {
- protocol = tcp
- socket_type = stream
- wait = yes
- user = amanda
- group = disk
- groups = yes
- server = /usr/local/libexec/amindexd
- }
to
- service amandaidx
- {
- protocol = tcp
- socket_type = stream
- wait = no
- user = amanda
- group = disk
- groups = yes
- server = /usr/local/libexec/amindexd
- }
I know of no server using tcp that the superserver waits upon for
connection completion.
On Mon, 2002-06-03 at 15:49, Rebecca Pakish wrote:
> >Try this. Do '/etc/init.d/xinetd restart'. Then, look in
> >/var/log/messages for the messages from xinetd, ending with a line like
> >this:
>
> [root@slaw amanda]# service xinetd restart
> Stopping xinetd: [ OK ]
> Starting xinetd: [ OK ]
> [root@slaw amanda]# tail -n 5 /var/log/messages
> Jun 3 14:38:57 slaw xinetd[1792]: time disabled, removing
> Jun 3 14:38:57 slaw xinetd[1792]: ftp disabled, removing
> Jun 3 14:38:58 slaw xinetd[1792]: xinetd Version 2.3.3 started with libwrap
> options compiled in.
> Jun 3 14:38:58 slaw xinetd[1792]: Started working: 4 available services
> Jun 3 14:39:00 slaw xinetd: xinetd startup succeeded
>
> >Look for any error messages, and check to see if that number matches the
> >number of xinetd based services listed as "on" by 'chkconfig --list'.
>
> No error messages, I count 4 xinetd services "on" and 4 available services
> in /var/log/messages (above)
>
> >That's not so interesting. What we're looking for is amindexd*debug.
> >That file just tells us that amrecover fails, which we knew already. :)
>
> Of course it's not interesting...I opened the wrong &*#@($! file!! :-) But
> this isn't getting to me, really...ugh
> amindexd*debug looks more like this:
>
> amindexd: debug 1 pid 1601 ruid 502 euid 502 start time Mon Jun 3 13:54:37
> 2002
> amindexd: version 2.4.2p2
> getpeername: Socket operation on non-socket
> amindexd: pid 1601 finish time Mon Jun 3 13:54:37 2002
>
> Is that interesting?
>
> >That looks like a service that is looping and getting shut off for a
> >while. Hmmm....
>
> After I restart xinetd and try to amrecover, I first get:
> [root@slaw amanda]# amrecover uadaily
> AMRECOVER Version 2.4.2p2. Contacting server on slaw.unterlaw.com ...
> amrecover: Error reading line from server: Connection reset by peer
>
> /var/log/messages says this:
> un 3 14:42:28 slaw xinetd[1802]: warning: can't get client address:
> Transport endpoint is not connected
> Jun 3 14:42:28 slaw xinetd[1803]: warning: can't get client address:
> Transport endpoint is not connected
> Jun 3 14:42:28 slaw xinetd[1804]: warning: can't get client address:
> Transport endpoint is not connected
> Jun 3 14:42:28 slaw xinetd[1805]: warning: can't get client address:
> Transport endpoint is not connected
> Jun 3 14:42:28 slaw xinetd[1806]: warning: can't get client address:
> Transport endpoint is not connected
> Jun 3 14:42:28 slaw xinetd[1807]: warning: can't get client address:
> Transport endpoint is not connected
> Jun 3 14:42:28 slaw xinetd[1808]: warning: can't get client address:
> Transport endpoint is not connected
> Jun 3 14:42:28 slaw xinetd[1809]: warning: can't get client address:
> Transport endpoint is not connected
> Jun 3 14:42:28 slaw xinetd[1810]: warning: can't get client address:
> Transport endpoint is not connected
> Jun 3 14:42:28 slaw xinetd[1811]: warning: can't get client address:
> Transport endpoint is not connected
> Jun 3 14:42:28 slaw xinetd[1792]: amandaidx service was deactivated because
> of looping
>
> So your looping theory is correct, sir.
>
> But why am I looping? (I'm getting to be like a 5 year old. The more
> questions you answer, the more questions I have?!)
>
>
>
> --
> Joshua Baker-LePain
> Department of Biomedical Engineering
> Duke University
>
