Re: ntp woes (and more-general questions about startup and logging)
- From: blmblm@xxxxxxxxxxxxx <blmblm@xxxxxxxxxxxxx>
- Date: 15 Oct 2009 14:27:53 GMT
In article <vilain-49614B.13335914102009@xxxxxxxxxxxxxx>,
Michael Vilain <vilain@xxxxxxxxxxxxx> wrote:
In article <7jlqr9F365tocU1@xxxxxxxxxxxxxxxxxx>,
blmblm@xxxxxxxxxxxxx <blmblm@xxxxxxxxxxxxx> wrote:
In article <vilain-955EC6.13253610102009@xxxxxxxxxxxxxx>,
Michael Vilain <vilain@xxxxxxxxxxxxx> wrote:
In article <7jbgtvF32cebjU2@xxxxxxxxxxxxxxxxxx>,
blmblm@xxxxxxxxxxxxx <blmblm@xxxxxxxxxxxxx> wrote:
In article <7j119iF32qa50U1@xxxxxxxxxxxxxxxxxx>,
blmblm@xxxxxxxxxxxxx <blmblm@xxxxxxxxxxxxx> wrote:
In article <7itqgbF33b1p5U3@xxxxxxxxxxxxxxxxxx>,
blmblm@xxxxxxxxxxxxx <blmblm@xxxxxxxxxxxxx> wrote:
In article <paul.nospam-037D10.13251504102009@xxxxxxxxxxxxxx>,
P. Sture <paul.nospam@xxxxxxxx> wrote:
[some text deleted]
Another thing to check is that on 10.4.11 (which I run), the
script creates a temporary file /var/run/NetworkTime.StartupItem which
it checks for. If that file exists, the script didn't run the "stop"
function.
Our 10.4 machines are 10.4.7. I don't know if that matters, but
I guess it might, because as best I can tell, the "stop" function
in the NetworkTime script decides whether to actually stop ntpd
based on whether it can find an appropriate PID rather than based
on whether the above-mentioned file exists. Hm.
On my 10.4.11 NetworkTime script, when it runs on shutdown (with the
"stop" argument by the shutdown or reboot process) it checks for the pid
file and uses that kill the ntpd process. It also checks if the
temporary file in /var/tmp exists and deletes it if so. That was all
I'm saying. Guess it's a language thing.
We do seem to be talking past each other, or something. :-) ?
(I'm tempted to guess from your name that you're not a native
speaker of English and you're wondering whether that's relevant.
I'm inclined to think not, though, because I wouldn't suspect
non-native-speaker from what you write.)
The point I was trying to make was that the NetworkTime script on
your 10.4.11 system seemed to be slightly different from the one
on our 10.4.7 system. But if I look more carefully at the script --
it's using a GetPID function in /etc/rc.common, which -- yes,
it does look for a file in /var/run. So -- my mistake, sorry.
Some things to check.
Is the NetworkTime startup script being run at startup (i.e. does that
temporary file exist).
The file exists, yes. I'm not sure what you mean by "at startup"
here -- are you asking about whether the script is being run to
start ntpd, or about what happens at boot time, or what?
Boot==startup. Can't think of any other possibility where "startup"
might mean something else. What context or senario were you thinking?
I couldn't think of another possibility either, but I thought
maybe there was one, since I thought I had mentioned [*] that the
problem is not that ntpd doesn't get started at boot, but that
it appears to sometimes be running but not operating correctly,
and restarting it doesn't always seem to help.
[*] Message ID <7jlqr9F365tocU1@xxxxxxxxxxxxxxxxxx>
(But of course you might have missed that post, or not remembered.)
Maybe it's a language thing. In Unix (or VMS), startup scripts run when
a system is booted. The shutdown scripts run when a system is shutdown
or rebooted. In 10.4, the scripts follow the SVR4 standard of running
with a "start" or "stop" argument. Each Unix is slightly different (and
10.5 is totally different) on how they do this. I'm most familiar with
SunOS 4 (BSD rc.local style) and Solaris (SVR4 /etc/rc.<x>/ scripts)
which do things differently. MacOS 10.5 uses launchd, yet another way
which I know nothing about.
Since you're admining systems from the command line, you should become
intimately familiar with how these work. Otherwise, you're in deep
sneakers.
Yes .... I'm more or less familiar with how all of this works on
the Fedora Linux systems I've worked with, but OS X is new to me.
Are you allowing UDP connections on port 123 on your system? How about
the smart hub it's connected to? ntpd and ntpdate use this port to
synchronize to the remote ntp servers.
I'm not sure how to check this, but the fact that it's working
*now* says to me that probably we are allowing the appropriate
connections. Maybe I'm confused ....
And I'm not sure what you mean by "smart hub" here -- I don't
know that much about the network configuration, except that
there are fewer restrictions on how they communicate with other
machines in the same domain than on how they communicate with
the outside world. (This has been described to me in terms of the
whole domain being "behind a firewall".)
Since you don't really know how your system is connected to the
underlaying networking hardware or even what that hardware is or how it
works, it's really up to you to decide if it's worth figuring out why it
didn't work and it does now.
Yes .... I've been thinking in terms of problems with system
software on the machines where things weren't working right,
but I guess that *could* be the wrong place to look. I had also
been thinking that the underlying network, and how its traffic
is managed, wouldn't have changed. But now that I think about
it, that might not be true. See below for a bit more.
The cabling or wireless connections eventually go to something that
connects you to the main network. That's either a hub with ports or a
smart hub with additional capabilities inside it to control (grant or
deny) what traffic (IP + port) goes to what port. Or you could have a
connection to a full-on router. Ultimately, some device was blocking
UDP packets to port 123 to your machine.
If you were attempting to connect to a NTP server that was on the public
internet, it was probably a firewall. But nowadays many of the big
routers have the ability to serve NTP themselves and radio receivers
that get NTP signals are really cheap now. You could have your own
statum 1 server in-house. I can't say who or what blocked it, but it's
working now. Your call on if you want to sleuth it out or just move on.
It might be in your best interested to learn your network topology and
environment so you can go to the right person to have something fixed.
Maybe it would be worthwhile to put in a few more of the details
as I understand them, though clearly I'm somewhat out of my depth
in trying to talk about hardware .... :
These OS X machines are part of a network owned and managed by
a smallish university. (I'll call this the "local network".)
Traffic between this local network and the outside world goes
through a router (routers?) managed by the university's ITS
department, and that hardware(?) does block some traffic (i.e.,
forms/imposes a firewall). The machine we've been trying to use
as a time server is part of the local network, though, and as
far I know, the ITS department isn't doing anything to restrict
network traffic among machines in the local network. I had been
thinking that none of this would have changed between the period
in which things didn't work and the period in which they do,
but that might be wrong; it's not as if I would necessarily know.
Attempt to check whether port 123 is being blocked .... From
another machine in the local network,
nmap -p 123 -sU -P0 local-time-server
and
nmap -p 123 -sU -P0 local-time-client
both report
Port State Service
123/udp open ntp
This means that all is well *now*, right? but possibly I would
have gotten different results when things were not working?
(I will try to find out from the ITS folks whether indeed they
changed something!)
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
.
- References:
- Prev by Date: Re: Possible Snow Leopard Guest Account Bug?
- Next by Date: Re: "fools buy macs"
- Previous by thread: Re: ntp woes (and more-general questions about startup and logging)
- Next by thread: Re: ntp woes (and more-general questions about startup and logging)
- Index(es):
Relevant Pages
|
