Re: xinetd log messages...?
On Thu, Sep 28, 2000 at 11:23:44AM +0100, Colin Watson wrote:
> will trillich <will@serensoft.com> wrote:
> >i've not deciphered some of these XINETD messages just yet--
> >if you can translate for me, or point me to The Path Of Enlightenment,
> >lemme know:
> >
> >Sep 27 20:37:20 server xinetd[883]: bind failed (Address already in use
> >(errno = 98)). service = telnet
> >Sep 27 20:37:20 server xinetd[883]: bind failed (Address already in use
> >(errno = 98)). service = smtp
> >Sep 27 20:37:20 server xinetd[883]: bind failed (Address already in use
> >(errno = 98)). service = ident
> >
> >how do i find out what's already "using an address?"
> >and how do i become convinced that ANYTHING is using it now?
>
> Try 'netstat -a', or 'netstat -an' if it bogs down trying to do DNS
> lookups. You might have to look for the port numbers from /etc/services
> rather than the service names. (It will throw several pages of
> information at you on a busy server.)
aha. very helpful gadget there, that 'netstat' command.
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 server:4658 mail.pinncomp.net:pop3 TIME_WAIT
tcp 0 0 localhost:4656 localhost:smtp TIME_WAIT
tcp 0 0 server:4655 mail.speedex.net:imap2 TIME_WAIT
tcp 0 1 server:www ftp.colormax.net:59242 FIN_WAIT1
tcp 0 20 linus:ssh wdt:2048 ESTABLISHED
tcp 0 0 *:auth *:* LISTEN
tcp 0 0 *:pop3 *:* LISTEN
tcp 0 0 *:smtp *:* LISTEN
tcp 0 0 *:ftp *:* LISTEN
tcp 0 0 *:time *:* LISTEN
tcp 0 0 *:daytime *:* LISTEN
tcp 0 0 *:discard *:* LISTEN
tcp 0 0 server:domain *:* LISTEN
tcp 0 0 linus:domain *:* LISTEN
tcp 0 0 1.2.3.4:domain *:* LISTEN
tcp 0 0 localhost:domain *:* LISTEN
tcp 0 0 *:ssh *:* LISTEN
tcp 0 0 linus:www *:* LISTEN
tcp 0 0 server:www *:* LISTEN
tcp 0 0 localhost:www *:* LISTEN
tcp 0 0 *:mysql *:* LISTEN
udp 0 0 *:discard *:*
udp 0 0 *:1141 *:*
udp 0 0 server:domain *:*
udp 0 0 linus:domain *:*
udp 0 0 1.2.3.4:domain *:*
udp 0 0 localhost:domain *:*
raw 0 0 *:icmp *:* 7
raw 0 0 *:tcp *:* 7
raw 0 0 *:ipv6-icmp *:* 7
raw 0 0 *:ipv6-icmp *:* 7
raw 0 0 *:ipv6-icmp *:* 7
in tinkering with tunl0 i got it up and running on 1.2.3.4 which is bogus;
now i can't kill it. (don't think that' related to my problem, tho...)
> The messages above indicate that some other service on your machine is
> already listening on the given ports.
>
> >the only service i use 'bind' in is telnet, to restrict it to my
> >secure internal 192.168.*.*, so it won't show up on any nmap scan
> >of my internet-visible ip address...
>
> bind() is a system call; *everything* that listens on a socket calls it.
> 'man 2 bind' if you need to do socket programming.
confusing -- in /etc/xinetd.conf there's a "bind" directive that allows
you to tell it "listen on this interface but not that one"...
> >Sep 27 20:52:00 server xinetd[1005]: warning: can't get client address:
> >Invalid argument
> >Sep 27 20:54:51 server xinetd[1005]: warning: can't get client address:
> >Invalid argument
> >
> >argument... from where? what client address are we looking for?
>
> That's how the C library describes the EINVAL error code, which is a
> fairly vague error saying "you passed the wrong argument to this
> function". I can't see anywhere in the source code where xinetd prints
> this message, though; maybe it's something xinetd calls, or maybe I'm
> missing something.
thanks for looking!
i notice that it only happens when i'm logged in, not when there's
server stuff going on by itself (http, ftp, etc). only when i've got
a shell login is there any trouble.
and now i notice in daemon.log that the server gets re-started
after every 'can't get client address...'
Sep 28 04:24:55 server xinetd[1005]: warning: can't get client address: Invalid argument
Sep 28 04:24:55 server identd[3726]: started
Sep 28 04:28:35 server xinetd[1005]: warning: can't get client address: Invalid argument
Sep 28 04:28:35 server identd[3771]: started
Sep 28 04:34:44 server xinetd[1005]: warning: can't get client address: Invalid argument
Sep 28 04:34:44 server identd[4179]: started
(logcheck filters out the non-alarming lines, so i didn't see this
earlier. may not be significant...)
anybody else have some clues?
Reply to: