Hey all,

So I've embarked on my Slackware journey, and so far it's been a blast. I don't know what it is about Slackware that I like, but it just seems "right". Also I must say that so far the Slackware community seems really nice.

I have though run into my first issue: NTP

I've always used NTP on all my servers to keep time correct. I've never been fond of adjusting time using a cronjob once or twice a day - I like the NTP way better.

I've installed the NTP package using slapt-get (wonderfull tool!) and I've setup my config file, but how do I go about starting NTP at boot?

I've found some references on this forum, but most talk about creating a script and putting it in rc.d. Is that the correct way, or should I just start it from rc.local?

Also from the Trustix NTP package I'm used to getting a time-slew message each time I start the daemon; this does not seem to happen with Slackware. How can I be sure the thing is even working?

I hope some Slackware/NTP experts out there can point me in the right direction.

Regards,
Thomas

Well, I'm not NTP expert, but I start it from rc.local and it works just fine. Just be sure in your config file, to point to pool servers and not to any specific time server. Using the pool servers is perfectly fine for personal use and spreads the load around.

I have this in /etc/rc.d/rc.local:

# Start the NTP daemon
#
if [ -x /etc/rc.d/rc.ntpd ]
then
/etc/rc.d/rc.ntpd start
fi

and this is /etc/rc.d/rc.ntpd (it must be executable):

#!/bin/sh
#
# start the Network Time Protocol
#
if [ ${1} = "start" ]
then
# set the clock from a public server
echo "Setting clock from ntp-1.mcs.anl.gov..."
/usr/sbin/ntpdate -v ntp-1.mcs.anl.gov ntp-2.mcs.anl.gov
sleep 2
echo "Starting Network Time Protocol daemon..."
>/tmp/ntp.log
/usr/sbin/ntpd -l /tmp/ntp.log
elif [ ${1} = "stop" ]
then
echo "Stopping Network Time Protocol daemon..."
pid=`/bin/ps -e | /usr/bin/grep ntp |\
/usr/bin/sed -e 's/^ *//' -e 's/ .*//'`
if [ "${pid}" != '' ]
then
kill ${pid}
fi
fi

Note the "/usr/sbin/ntpd -l /tmp/ntp.log" that logs activity to /tmp/ntp.log (or wherever you'd like); that's how you tell it's working (look at the log every so often). I also clean that log out with every start so it doesn't get huge.

The servers I use (in /etc/ntp.conf) are:

server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
#
# if ntpq -pn shows only one server
# (instead of three different addresses)
# maybe a buggy DNS name resolver, so
# use these instead
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org

You need the local clock server so that if your internet connection goes away ntp will continue to run against the local clock then re-sync to a server once the internet comes back.

Hope this helps.

Thank you both for the assistance. NTP is working like a charm now.

I use a similar approach as that posted by tronayne. However, for the sake of future visitors to this thread, such an approach will not succeed well with dialup users, as I currently am.

When the rc.ntpd script launches the NTP daemon, the NTP daemon expects to be online. This is not going to happen with typical dialup users. I therefore have modified my rc.ntpd script to use the ping command to check whether I am online before launching the NTP daemon. An unsuccessful ping and the script terminates without starting the NTP daemon.

Should I one day find myself with a broadband connection, I need not modify my existing rc.ntpd script because the ping command will have succeeded and NTP will have direct online access to the time servers.

An addition to configuring my rc.d scripts in such a manner, I use a script that I wrote from scratch that handles NTP on-the-fly after I dial up and make an online connection.

Just one quick comment - why not set the clock from 0.us.pool.ntp.org in the beginning of the script too, in order not to potentially overwhelm ntp-1.mcs.anl.gov on frequent reboots?

-Y1

Using the pool names is exactly what should be done unless you've contacted the administrators of the named servers and gotten their permission to get time from them.

There is no benefit to using specific servers over pool servers, unless you know you're really really close to one (like, you're at the university where it's hosted). The pool servers are not just some random machines that have had their clocks synched to someone's cheap digital wristwatch. Every single one of them is synched to a high-tiered server, and can be considered quite accurate.

I'm no expert with ntp, but IIRC both pool and specific public servers may be used, depending upon the circumstances.

If a person wants only to sync a single computer clock and is not serving other computers on a LAN and does not need to run the ntp daemon, then I believe ntpdate may be used with any of the listed lower-tiered public ntp servers. The ntpdate command is a one-shot sync as opposed to the continuous synchronizing performed by the ntp daemon. The ntp site has a list of such public servers. ntpdate also is useful for people with a non-continuous internet connection, such as dialup, where running the daemon is challenging. For people with minimal time sync needs and clocks that drift little, using ntpdate and a public server located nearby makes sense, although pool servers may be used too.

Using both ntpdate along with the ntp daemon also makes sense if the computer clock drifts a lot. Using ntpdate to perform a one-time sync will ensure that the ntp daemon does not fail because of too large of a drift.

If a person is going to use the ntp daemon to maintain the clock, then the pool servers should be used. This is configured in the /etc/ntp.conf file:

server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org

However, this configuration will tap into pool servers anywhere in the world, which might mean incorrect time syncs. According to the ntp pool web page, users should use a geographical prefix to obtain better time results:

server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org

or

server 0.mx.pool.ntp.org
server 1.mx.pool.ntp.org
server 2.mx.pool.ntp.org

etc. If there are an insufficient number of country servers, which tends to reduce reliability, then the prefix should refer to the larger regional areas.

Please let me know if I am incorrect.

I suppose if you were rebooting every 10 milliseconds that might be a problem.

One query, at boot only, is no big deal (and, oh, by the way, I did ask for permission to do so and did receive an OK from the site administrator some years back). At the time, the pool didn't exist and, when the pool first came on line, it didn't always work. Nowadays, well, it's pretty much always there (and I do have the pool servers in ntp.conf) and I suppose one could replace the government NTP servers with a pool server at start-up. Main thing is, one reliable hit to set the clock at start-up and that's all it takes.

Its nice you got permission, but think about one boot multiplied hundreds of thousands of times. Lots of people see LQ and lots of people take stuff from it. And if you don't believe me that this kind of stuff can spiral out of control, this article spells out a number of accidental NTP abuse problems.

I would bet if you asked the administrator today, you would probably get a different answer.

Woodsman,

Would you mind posting your rc.ntpd script that includes the ping command?

I like the idea of checking for connectivity before the NTP daemon starts.

Thanks,
Gary

No, I don't mind, but you caught me in the middle of writing a mini how-to on the same topic. Barring unforeseen interruptions I should be finished in a day or so. I'll post a message to this thread so you (and anybody else) will know and then can download the files. Thanks for your patience and interest!

I've come across a problem with the 10.2 NTP package: It doesn't work right.

In order for it to work as "intended", open ntp.conf and change the following line:

restrict default noquery notrust nomodify

to

restrict default noquery nomodify

And voila! everything works.

I don't know why the ntp.conf file is setup like this, but then again, I am a complete Slackware beginner.

Regards,
Thomas

My memory is a little fuzzy, but IIRC there was a file somewhere generated by pppd that was supposed to be useable as an indicator that the network link is up, for this sort of reason. You might want to rummage through their docs to see if you can spot it.

Well, it won't mean incorrect time syncs in the sense that the clock will wind up dramatically wrong, it'll just mean potentially less accurate synchronization. Someone's clock might wind up being a whole second off. This won't affect it's ability to keep regular time (once it's gotten a feel for your local clock drift) in any significant way.