Bug 21453 - ntp 4.0.99j bug
ntp 4.0.99j bug
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: ntp (Show other bugs)
7.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Preston Brown
http://ssadler.phy.bnl.gov/adler
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-11-28 18:17 EST by adler
Modified: 2008-05-01 11:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-01 12:36:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description adler 2000-11-28 18:17:09 EST
ntpd does not start up properly if the server entry in
/etc/ntp.conf is in the XX.XX.XX.XX notation. (i.e.
the number notation. e.g. 130.199.3.24) It seems
to require that the server entry be in the text
name notation in order for the deamon to startup
properly. 

The signature of the bug is, that if the
server entry in /etc/ntp.conf is in the number
notation, then an ntptrace to the deamon will
result in a *timeout*. If the server entry in
/etc/ntp.conf is in the text notation, (i.e.
horus.s3.bnl.gov) then the server starts up
and an ntptrace to the daemon respons properly
and after a few minutes the system is sync'ed
to a master clock.

I hope this report is clear enough.
Cheers Steve.
Comment 1 Preston Brown 2001-02-05 15:55:09 EST
I'm not sure about ntptrace, but I don't think there is a problem in 4.0.99k at
least.

/etc/ntp.conf has:

207.175.42.166 (our internal clock server) as the server line.

strace fragment of the running ntpd:

--- SIGALRM (Alarm clock) ---
sigreturn()                             = ? (mask now [])
select(7, [4 5 6], NULL, NULL, NULL)    = ? ERESTARTNOHAND (To be restarted)
--- SIGALRM (Alarm clock) ---
sigreturn()                             = ? (mask now [])
gettimeofday({981403334, 984939}, NULL) = 0
sendto(4, "\343\0\6\360\0\0\0\0\0\0\0\21\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 48, 0,
{sin_family=AF_INET, sin_port=htons(123),
sin_addr=inet_addr("207.175.42.166")}}, 16) = 48
select(7, [4 5 6], NULL, NULL, NULL)    = 1 (in [6])
gettimeofday({981403334, 986060}, NULL) = 0
select(7, [4 5 6], NULL, NULL, {0, 0})  = 1 (in [6], left {0, 0})
recvfrom(6, "$\4\6\357\0\0005E\0\0\33\266\317\257+\266\276)\204\230"..., 500, 0,
{sin_family=AF_INET, sin_port=htons(123),
sin_addr=inet_addr("207.175.42.166")}}, [16]) = 48
select(7, [6], NULL, NULL, {0, 0})      = 0 (Timeout)
gettimeofday({981403334, 987017}, NULL) = 0
gettimeofday({981403334, 987146}, NULL) = 0
gettimeofday({981403334, 987350}, NULL) = 0
select(7, [4 5 6], NULL, NULL, NULL)    = ? ERESTARTNOHAND (To be restarted)

It is clearly connecting to the host.


Note You need to log in before you can comment on or make changes to this bug.