2.6.14-rc* / xinetd

2.6.14-rc* / xinetd

[Klaus Dittrich]

SMP-system (2xP4)

I noticed a huge cpu usage of xinetd with 2.6.14-rc4 
starting with the first ntp request.

12:45:10 xeon2 xinetd[1245]: service dgram_time, recvfrom: Bad address (errno = 14)
12:45:40 xeon2 last message repeated 651771 times
12:46:41 xeon2 last message repeated 1329225 times
12:47:42 xeon2 last message repeated 1308902 times

2.6.13.3 works fine.
--
Klaus

Re: 2.6.14-rc* / xinetd

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

On Wed, 12 Oct 2005 16:36:57 +0200, Klaus Dittrich said:
> I noticed a huge cpu usage of xinetd with 2.6.14-rc4 
> starting with the first ntp request.

Umm.. why is xinetd listening for ntp requests at all?  I'm pretty sure that
xinetd fighting with xntpd for control of the socket isn't going to work nicely,
although I admit being mystified as to (a) why this ever worked for you and
(b) what specifically changed in -rc4 to cause the CPU spin.

What was the most recent kernel known to work, and what does the xinetd
config file entry for NTP look like?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: 2.6.14-rc* / xinetd

[Klaus Dittrich]

Valdis.Kletnieks@vt.edu wrote:

>On Wed, 12 Oct 2005 16:36:57 +0200, Klaus Dittrich said:
>  
>
>>I noticed a huge cpu usage of xinetd with 2.6.14-rc4 
>>starting with the first ntp request.
>>    
>>
>
>Umm.. why is xinetd listening for ntp requests at all?  I'm pretty sure that
>xinetd fighting with xntpd for control of the socket isn't going to work nicely,
>although I admit being mystified as to (a) why this ever worked for you and
>(b) what specifically changed in -rc4 to cause the CPU spin.
>
>What was the most recent kernel known to work, and what does the xinetd
>config file entry for NTP look like
>  
>

2.6.13.3 works. I can compile an try 2.6.14-rc[1,2,3].

service time
{
    type        = INTERNAL
    id          = dgram_time
    socket_type = dgram
    protocol    = udp
    user        = root
    wait        = yes
    only_from   = 192.168.168.36 192.168.168.39
}


This setup worked for years now. The machine
(192.168.168.32) is the time-server and I have
chosen this setup to simulate and verify a real
world scenario.

/etc/ntpd.conf
..
driftfile /etc/ntp.drift
logfile   /var/log/ntp 
#authenticate no
server 127.127.8.0 prefer mode 2    # Meinberg ANZ_14 (Standart Telegramm)
server 127.127.1.1                  # Local clock in case of disaster
fudge  127.127.1.1 stratum 10       # Poor stratum for local clock
--
Klaus

Re: 2.6.14-rc* / xinetd

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 207 bytes --]

On Wed, 12 Oct 2005 20:27:00 +0200, Klaus Dittrich said:

> service time
> {
>     type        = INTERNAL
>     id          = dgram_time

That, my friends, is UDP port 37, not UDP port 123 where NTP lives.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: 2.6.14-rc* / xinetd

[Klaus Dittrich]

Valdis.Kletnieks@vt.edu wrote:

>On Wed, 12 Oct 2005 20:27:00 +0200, Klaus Dittrich said:
>
>  
>
>>service time
>>{
>>    type        = INTERNAL
>>    id          = dgram_time
>>    
>>
>
>That, my friends, is UDP port 37, not UDP port 123 where NTP lives.
>
>  
>

The time requester is a router. I looked up
it's configuration and indeed TIME/UDP is the
protocol used.

You are right, I mixed up ntp with time. Sorry.

So, the corretced message is ..

I noticed a huge cpu usage of xinetd with 2.6.14-rc4
starting with the first time/udp request.

I will try older rc's today to narrow the point in time
this problem started.
--
Klaus

Re: 2.6.14-rc* / xinetd

[Klaus Dittrich]

This (service dgram_time, recvfrom: Bad address (errno = 14))
behavior of the kernel started with 2.6.14-rc2-git9.

I am not a kernel-guru and the log shows several net changes.
--
Klaus