RE: the previous three...
h...I am sure I have seen cases where ntpd is running, but no
associations are active; therefore, I am not sure that just testing if
ntpd is running fully covers all possible cases..
--
ntp brought up before network is ready; fails not resolve any ip or host
You say addresses on a local DNS server will resolve. What about the
vast majority of people who do not have a local DNS server and rely on
internet DNS?
--
ntp brought up before network is ready; fails not resolve any ip or host names;
ntp does not recover
RE: the previous three...
h...I am sure I have seen cases where ntpd is running, but no
associations are active; therefore, I am not sure that just testing if
ntpd is running fully covers all possible cases..
--
ntp brought up before network is ready; fails not resolve any ip or host
You say addresses on a local DNS server will resolve. What about the
vast majority of people who do not have a local DNS server and rely on
internet DNS?
--
ntp brought up before network is ready; fails not resolve any ip or host names;
ntp does not recover
cwsupport, this should be a great help to getting this fixed (has been
known a LONG time--should have been fixed in Gutsy and Hardy). However,
there is one part of your logic I do not understand:
After all - ntpdate should only be used automatically if ntp as a
service has been started.
I think
cwsupport, this should be a great help to getting this fixed (has been
known a LONG time--should have been fixed in Gutsy and Hardy). However,
there is one part of your logic I do not understand:
After all - ntpdate should only be used automatically if ntp as a
service has been started.
I think
J Carrera, I do not know what you mean by 'write to hardware switch'
to ntpdate.
Sorry, I am on long travel and don't have my linux machine. As I recall
it is something involving --hwclock or something like that. It may
even be a separate command rather than an ntpdate switch. Maybe date
I did some web research. The command is hwclock --systohc
This should be part of the fix (or at least made an option somehow) to run
after ntpdate,
for the reason previously cited.
--
ntp brought up before network is ready; fails not resolve any ip or host names;
ntp does not recover
J Carrera, I do not know what you mean by 'write to hardware switch'
to ntpdate.
Sorry, I am on long travel and don't have my linux machine. As I recall
it is something involving --hwclock or something like that. It may
even be a separate command rather than an ntpdate switch. Maybe date
I did some web research. The command is hwclock --systohc
This should be part of the fix (or at least made an option somehow) to run
after ntpdate,
for the reason previously cited.
--
ntp brought up before network is ready; fails not resolve any ip or host names;
ntp does not recover
Moderators may delete this post if you wish..
I just have to say it is truly incredible this issue is not fixed in
Hardy. It has been known for a long time and the fundamental cause is
known--the necessary sequence of getting the internet connection to be
fully functioning (eth0, dhcp, etc)
Onno, would you please elaborate on the patch you posted...
-What files does it modify, delete, or add?
-What, in detail, does it do, exactly, step by step?
-How does one employ/deploy it?
-To what versions can it be applied?
Thanks.
--
ntp brought up before network is ready; fails not resolve
It is illuminating to look at syslog in an editor/viewer just after a
boot and search for 'ntp.' That will show you the ntpd and ntpdate
calls--easily showing if multiple attempts are happening. You can also
see if ntpd is making associations, look to see if interfaces are up, if
dhcp addresses
Moderators may delete this post if you wish..
I just have to say it is truly incredible this issue is not fixed in
Hardy. It has been known for a long time and the fundamental cause is
known--the necessary sequence of getting the internet connection to be
fully functioning (eth0, dhcp, etc)
Onno, would you please elaborate on the patch you posted...
-What files does it modify, delete, or add?
-What, in detail, does it do, exactly, step by step?
-How does one employ/deploy it?
-To what versions can it be applied?
Thanks.
--
ntp brought up before network is ready; fails not resolve
It is illuminating to look at syslog in an editor/viewer just after a
boot and search for 'ntp.' That will show you the ntpd and ntpdate
calls--easily showing if multiple attempts are happening. You can also
see if ntpd is making associations, look to see if interfaces are up, if
dhcp addresses
A note to all:
updates released sometime shortly before 1-27-08, when I installed them in
Gutsy, REVERTED the change of S24dhcdbd to S13dhcdbd start priority in rc5.d
back to S24 !!
(I used sysv-rc-conf -p ' tool to make the previous changes by the way)
This reversion caused the previous
BTW, what does Declined for Gutsy by Henrik Nilsen Omma mean?
Does that mean the developers have ruled out fixing it?
--
ntp brought up before network is ready; fails not resolve any ip or host names;
ntp does not recover
https://bugs.launchpad.net/bugs/114505
You received this bug
BUG CONFIRMED
A WORKAROUND FOUND
heindsight's method worked for me, with one additional change that he also
suggested at
http://ubuntuforums.org/showthread.php?t=647559page=5 ...
specifically, changing S24dhcdbd to S13dhcdbd in /etc/rc[2,3,4,5].d (I
used sysv-rc-conf -p ' by the way) so
As others, I confirm for Gutsy 7.10...
I do not see a consensus in the preceding comments regarding a for-
certain solution. It is absolutely a situation that needs to be
resolved, and, boy, would I like to see a documented change here that
does.
heindsight, in
20 matches
Mail list logo
