--
$$$ Emanuele Lombardi
$$$ mail: AMB-GEM-CLIM ENEA Casaccia
$$$ I-00060 S.M. di Galeria (RM) ITALY
$$$ mailto:lele_at_mantegna.casaccia.enea.it
$$$ tel +39 06 30483366 fax +39 06 30483591
$$$
$$$ * This transmission was made possible by 100% recycled electrons.
$$$ |||
$$$ \|/ ;_;
$$$ What does a process need | /"\
$$$ to become a daemon ? | \v/
$$$ | |
$$$ - a fork o---/!\---
$$$ | |_|
$$$ | _/ \_
$$$* Contrary to popular belief, UNIX is user friendly.
$$$ It's just very particular about who it makes friends with.
$$$* Computers are not intelligent, but they think they are.
$$$* True programmers never die, they just branch to an odd address
---------------------------------------------------------------------------------
Jeffrey Mogul <mogul_at_pa.dec.com>
I checked with the Tru64 engineer who maintains NTP (I do
NOT work for the product group myself), who replied:
This is a known problem. I think the reason this is happening is
because the server list for 'ntpdate' is given as names instead of
addresses. Ntpdate tries to contact DNS/NIS (whatever is
configured) to figure out the address. That's what's taking so
long (actually it is a standard DNS/NIS timeout).
They can fix this one of 2 ways. First put the timeserver names
into the /etc/hosts file (recommended). Or they can replace the
timeserver names with IP addresses in the /etc/rc.config file.
I hope this solves your problem.
---------------------------------------------------------------------------------
Michalis Kabrianis <M.Kabrianis_at_asyk.ase.gr>
How about sending the process to the background?
(i.e adding an & at the end of the line?)
---------------------------------------------------------------------------------
Joerg Bruehe <joerg_at_sql.de>
In your place, I would do a 'ping' to the timeserver(s)
in the script and check its return code.
AFAIK, ping cannot block because it has a timeout, but
you should try just to be sure.
Then, check ping's return code and ask the server's date
only if the ping was o.k.
---------------------------------------------------------------------------------
Werner Rost" <werner.rost_at_boge.mannesmann.de>
Try "nohup /usr/sbin/ntpdate -b o 3 myserver1 myserver2 myserver3 &"
---------------------------------------------------------------------------------
Cherie Willoughby <willough_at_lucent.com>
Do you have your ntp.conf file set up to use the local clock if others are not
available?
---------------------------------------------------------------------------------
Nikola Milutinovic <Nikola.Milutinovic_at_ev.co.yu>
> It works properly if the net is up and the ntp servers do'nt reply,
> but it stops the whole booting process if the net is down. In this case
So, if you are on the net and all other NTP servers are not, then it goes
through?
That would mean that if you are on the net, the interface is brought down. Now,
this shouldn't be the default behaviour. On all of my Alpha's interface is
brought up, even if the cable is unplugged. Basically, your "ntpdate" is not
struggling with the lack of NTP servers, but with the lack of network and
network routes.
> I get the following messages on the console
> ....
> Setting the current time and date with ntpdate
> and the only way to continue the boot sequence is to manually CONTROL-C
> I tried to insert the switch -t 1 in the ntpdate command, but the
> result is the same (infact man says that -t 1 is set by default)
And it is when the net is up and all NTP servers are down, right? So, we can
conclude that in your problem, it doesn't even get there. Looks like the problem
I mentioned above, and it looks like kernel problems. Like, ntpdate calls system
to establish connection to NTP servers and kernel just hangs there, being unable
to find apropriate interface to route packets.
One good test is to test ping in that situation. If it gives "Net unreachable"
or "No route to host", then there is no route and it might be the explanation.
========================== My question ++++++++++++++++++++++++++
Dear colleagues,
I just setup xntpd (via ntpsetup) on all my True64 Unix 4.0d machines.
All is fine, but I discovered that if I boot a machine which is
disconnected from the network, the booting process stops while
executing /sbin/init.d/settime
In the above script the following command is executed
/usr/sbin/ntpdate -b o 3 myserver1 myserver2 myserver3
and it stops forever waiting for the net to come up.
It works properly if the net is up and the ntp servers do'nt reply,
but it stops the whole booting process if the net is down. In this case
I get the following messages on the console
....
Setting the current time and date with ntpdate
and the only way to continue the boot sequence is to manually CONTROL-C
I tried to insert the switch -t 1 in the ntpdate command, but the
result is the same (infact man says that -t 1 is set by default)
I think this is a disadvantage if the boot is an automatic reboot
following any unattended shutdown (power loss and others...)
Can you help me in solving this problem?
Received on Tue Nov 23 1999 - 10:02:30 NZDT
This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:40 NZDT