[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ 18 ] [ next ]
Computers have a clock to keep time. Usually there is a
hardware clock with battery backup to keep time when the computer is off. The
operating system (for example Linux) runs its own clock, and from this clock
comes the time shown by commands such as date in Linux and
time in DOS.
The hardware clock is usually accurate enough, provided that the battery has not run out. If the time shown by the computer when you turn it on is wrong by several months or years, it is worth checking if the battery is still usable.
The "software" clock in the operating system usually has drift, either systematic or random. This drift means the clock runs too fast or too slow. For this reason it is nesessary to use some accurate time source to syncronize the operating system clock if accurate time is needed.
To see the time on Debian GNU/Linux, use the command date. For
example
$ date
Fri Oct 23 04:45:51 EEST 1998
The above command shows the day of the week, the month, the day of the month, the time, the time zone and the year. The time zone also shows whether Daylight Saving Time is in use (in the example, the base time zone is EET,and the extra S means Saving).
In Debian GNU/Linux and other Unix, the command time does not show
time. It is used to time command excecutions. If you have some command that
takes a fair amount of time to execute, and you do not feel like standing by
with a stopwatch, you can see how long it took by running the command as
argument to time. This example may clear things up:
$ time sleep 60
real 1m0.045s
user 0m0.000s
sys 0m0.000s
If You have root privileges, you can also change the time with the command
date (see the man page date(1)). If you are
connected to the Internet or have other Unix computers on your LAN, see Syncing time, rdate and NTP, Section 16.4 for easier
ways to set time.
When setting the time manually, the time string may be confusing. The command
date --set accepts the date and time in many formats. You can
read the sh-utils info document, or use the example below to figure out one
possible format. There date is given in ISO 8601 standard format YYYY-MM-DD
for Year-Month-DayOfMonth, and time of day using 24 hour clock. Leading zeros
are significant.
date --set 1998-11-02
date --set 21:08:0
The above two commands set the date to 2nd November 1998, and time to eight minutes past 9pm.
To see the time in UTC, use command date -u.
If you are running X Window, you may have a clock display somewhere on the
screen. If not, you can obtain it by running the command xclock,
which is part of the xbase package. The bare xclock
command gives you an analog clock (with big hand, little hand, and an optional
seconds hand). You can get a digital clock (with xclock
-digital). See the man page xclock(1)for more information.
When you installed the base system of Debian GNU/Linux, you set the
Timezone. You can check how you have set the Timezone by
looking at the file /etc/timezone. If you want to change the
timezone configuration, see Changing the timezone after
installation, Section 16.1.1.
$ cat /etc/timezone
Europe/Helsinki
$
The time zone is needed because Unix computers keep time in Universal Time (UTC), and local time is calculated from this. UTC is solar time on meridian 0. UTC was previously called Greenwich Mean Time (GMT) because meridian 0 passes through the old Royal Observatory in Greenwich, which is part of London, England.
UTC is constant, and is not subject to Daylight Saving Time or other changes. This is what makes it useful for syncronising computers. As long as the base time is kept in UTC, computers all over the world can be synchronised and yet maintain their local time information.
If you were to set your Debian GNU/Linux computer to use local time, without taking account of timezones, you would lose the benefit of automatic DST changes. We do not recommend this! However, it may be necessary to compromise by setting your hardware clock to local time (see Multiboot with operating systems not understanding timezone, Section 16.3). In this document, we assume that you have configured your computer to use UTC.
To change the computer to use UTC after installation, edit the file
/etc/default/rcS, change the variable UTC to
no. If you happened to install your system to use local time,
just change the variable to yes to start using UTC. It is best to
reboot after editing /etc/default/rcS to get the changes
effective.
If the Timezone is correctly set up, and the timezone configuration files are reasonably current, the local time shown by the operating system will change to Daylight Saving Time and back to normal time automatically on the correct dates. If the timezone files you have are old, there may be problems because DST start and end dates are not determined by a physical phenomenon, but are chosen by national institutions. Sometimes these dates are changed, for example, the European Union changed the end date from the last Sunday in September to the last Sunday in October in 1995.
For this reason, you should make sure that your libc6 package is
kept reasonably up to date. This package, from Debian GNU/Linux 2.2 onwards,
contains the timezone data.
If the timezone is not set or is wrong, the superuser can run
tzconfig to configure it after the operating system is installed
(see man page tzconfig(8)).
If there are other users, it is a good idea to notify then that the system Timezone has changed.
If you do not have root privileges or want to set for yourself a different
timezone than the one the system uses, you can set the environment variable
TZ. Use the command tzselect to show what value to
use for TZ.
Example on using TZ:
$ date
Sun Nov 1 19:49:38 EET 1998
$ export TZ=PST
$ date
Sun Nov 1 17:49:59 PST 1998
As you can see, for this user date shows a different time. (but
this seems wrong, since Pacific Standard Time should be 09:49???. What's
happening???).
The command for setting the hardware clock is hwclock. (This was
not in Debian before 2.0. In earlier releases, the command was
clock.)
If you use the date command to change time, it is worth setting
also the hardware clock to the correct time. Otherwise, the time is wrong
after the next reboot, since the hardware clock keeps the time when power is
turned off. When the clock in the operating system shows the correct time, set
the hardware clock like this:
dilbert# date
Sun Nov 1 18:56:50 EET 1998
dilbert# hwclock --systohc --utc
dilbert#
Remember to add the --utc -option if the hardware clock is set to
UTC!
See man page hwclock(8) for more information.
At least from Debian version 2.2 onwards, the system automatically saves the
system time to hardware clock on shutdown, and sets the system clock from
hardware clock when Debian boots up. This is done in the script
/etc/init.d/hwclock.sh.
If you have a multiboot configuration, where you have some other operating system(s) on the same computer, and during boot choose which one to start, you may get confused about the correct time. If the other operating systems do not understand timezones, they think UTC is the local time and show the wrong time (unless you live in London, England or some other place in the same timezone).
DOS, OS/2 and Windows except NT do not use timezones. If you need to have the correct local time in these operating systems, you have to set the clock to local time. Debian Linux can live with this and it works, but if your main operating system(s) understand timezones, use them.
If you have another Unix computer which you know keeps the correct time, with
root privileges you can set the time with the command rdate. For
example:
rdate somehost.domain.com
Even if you do not have an accurate time source, it is still a good idea to set all your computers to the same time, so that you can compare time stamps between hosts. To keep the clocks syncronized, You can start rdate once daily from cron.
If the hardware clock does not keep the correct time, it is possible to set the correct time when the operating system boots. For this, there must be some other host in the LAN where the time can be received. Here is an example:
create the file /etc/init.d/rdate
$ cat rdate
#! /bin/sh
#
# rdate Execute the rdate command.
#
# Version: 1998-11-01 [email protected]
#
PATH=/sbin:/bin:/usr/sbin:/usr/bin
HOST=dilbert
# Set operating system time from other host in LAN.
if [ -x /usr/sbin/rdate ]
then
/usr/sbin/rdate $HOST
fi
chmod a+rx /etc/init.d/rdate
Create a symbolic link to that file in directory /etc/rc2.d
cd /etc/rc2.d
ln -s ../init.d/rdate S19rdate
At next reboot, you should see the time being set.
Remember to set execute permission to /etc/init.d/rdate. If You
are wondering what the number S19 above means, read chapter ???. The key is to
run rdate after netbase which starts networking, and before xntp3 or some other
process where time is needed starts.
If you are connected to the Internet, you can install an NTP client, for
example ntp or xntp3 in Debian version 2.1 and older.
This uses the Network Time Protocol RFC 1305 to synchronise clocks to a few
tens of milliseconds precision. If you need this kind of precision or
better, see also Radio clocks, Section 16.6.
See the excellent documentation that comes with ntp, in the Debian
package ntp-doc. It is very thorough and thus long. If you think
reading documents is a waste of time, just ask your Internet Service Provider
or system administrator for NTP server names, or look up the nearest one in
"List of Public NTP Servers" in
http://www.eecis.udel.edu/~mills/ntp/servers.html . If you start using an NTP
server, it is usually polite to notify the server's administrator of the fact.
Do not configure your system to query level 1 NTP servers! If you think you need to do this, you are almost certainly wrong!
Once you know an NTP server, edit the file /etc/ntp.conf to add at
least one server line. Here is an example:
# /etc/ntp.conf, configuration for xntpd
logfile /var/log/xntpd
driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server ntp.somedomain.something
server ntp.something.else
Note, that I changed the actual server name in the above example, to prevent
all Debian GNU/Linux users from blindly using that one server. Everything else
except the server lines was there after xntp3 installation.
If you do not have a permanent Internet connection, then running NTP client is
not a good solution. NTP client syncronizes relatively often, and needs the
Internet connection to be always on. If you have a dial up Internet
connection, you can run the command ntpdate (also in
ntp package) to syncronize each time you connect.
Another possibility is to set cron to run ntpdate once daily, this
gives good accuracy for most uses. The following is an example script that can
be started from cron and runs ntpdate. This scripts assumes the
/etc/ntp.conf is correctly set up, since it gets the server names
from that file.
dilbert# cat /etc/cron.nightly/ntpdate
#!/bin/sh
#
# Last modification: Sat Aug 8 05:27:07 EEST 1998
# ntpdate cron nightly
NTPDATE=/usr/sbin/ntpdate
LOGFILE=/var/log/xntpd
NTPCONFFILE=/etc/ntp.conf
NTPSERVERS=
GREP=/usr/bin/grep
CUT=/usr/bin/cut
if [ -f $NTPCONFFILE ] ; then
echo "===========================" >> $LOGFILE
echo "<<< `date` " >> $LOGFILE
for i in `grep ^server $NTPCONFFILE | $CUT --fields 2 --delimiter \ `
do
NTPSERVERS="$NTPSERVERS $i"
done
$NTPDATE $NTPSERVERS >> $LOGFILE
###echo $NTPDATE $NTPSERVERS $LOGFILE
echo ">>> `date` " >> $LOGFILE
fi
exit 0
dilbert#
Debian GNU/Linux has also the command netdate, see man page
netdate(8L) for more info. It uses the protocol defined in RFC
868.
If you have several hosts that you want to synchronise, you should not let them all separately synchronise to an outside NTP server. This puts a load on the NTP server, and if it is a public and free service, the people there may start to dislike you! At least ask if it is OK to sync all of your machines there.
A better way is to set up one of your hosts as an NTP server, sync that to the
outside NTP server and the rest of your hosts to your own NTP server. The
ntp package provides the server component as well, so you just
need to configure it. This is not particularly difficult either, but you
should read the documentation and understand the peer concept and stratum
hierarchy.
If you want better accuracy or cannot synchronise with an NTP server in the public Internet, you can purchase a radio clock. These get the time from time servers that use a very accurate clock, and broadcast time signals using radio waves.
There are radio clocks that need a ground based transmitter near enough to get the signal. If you get one of these, make sure you can receive the signal on the location where you plan to use it. The transmitters are ground based, so they don't work accross the globe.
Another kind of radio clock uses a Global Positioning System GPS receiver. GPS satellites circle the globe in low earth orbits, and there should always be at least four above the horizon. They are mainly used for navigation, but the principle they work on is based on sending time signals. For time synchronisation it is enough to get the signal from one satellite, but usually it is necessary to install the GPS antenna outdoors to get good reception.
Timestamps in files are in UTC. The command ls -l shows file
timestamps in local time using the Timezone in effect. Because timestamps are
in UTC, timestamps can be compared between separate computers. This can lead
to problems if the clocks are not syncronized.
Consider this situation: You log in host B, which NFS loads your home directory
from NFS server host A. You edit some file, save it and start
make. If the clocks in hosts A and B are not syncronized,
make may complain that the file modification time is in the
future, or not compile the file because the object is newer.
The times in cron are local times. This means, that if you configure cron to start some program at 7 in the morning, it is 7 in the morning local time as determined by the system Timezone.
This causes headaches, if the system Timezone is not the same you have set for yourself using the TZ enviroment variable, or you have two host in different Timezones that need to start someting at the same time on both hosts.
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ 18 ] [ next ]
Debian GNU/Linux System Administrator's Manual
[email protected][email protected][email protected]