System Time Partial list of Terms
•/usr/share/zoneinfo
•/etc/timezone
•/etc/localtime
•/etc/ntp .conf
•date
•hwclock
•ntpd
•ntpdate
•pool .ntp .org
LX0-104 Exam Objectives (N)
Showing posts with label system time. Show all posts
Showing posts with label system time. Show all posts
Friday, December 9, 2016
System Time VI
Tracking NTP Daemon
Once the NTP daemon has been started, you can use two commands to keep track of how the
ntpd daemon is working:
1) ntpq –p
This command queries the status of the ntpd daemon. Here is an example:
openSUSE:~ # ntpq –p
remote refid st t when poll reach delay offset jitter
==============================================================================
*LOCAL(0) .LOCL. 10 l 14 64 3 0.000 0.000 0.001
helium.constant 18.26.4.105 2 u 12 64 1 96.614 -31.777 0.001
The columns in the output include the following:
• remote
Specifies the hostname or IP address of the time provider.
• refid
Specifies the type of the reference source.
• st
Specifies the stratum of the time provider.
• when
Specifies the number of seconds since the last time poll.
• poll
Specifies the number of seconds between two time polls.
• reach
Displays whether or not the time server was reached in the last poll. Each
successful poll increments this field by 1.
• delay
Specifies the time (in milliseconds) that it took for the time provider to
respond to the request.
• offset
Specifies the time difference between the local system clock and the time
provider (in milliseconds).
•jitter
Specifies the size of time discrepancies (in milliseconds).
2) ntptrace
The ntptrace utility traces how the time consumer is receiving time from the
provider. It lists the time provider’s name, its stratum, and its time offset from the system
clock on the local system.
LX0-104 Exam Objectives (N)
Once the NTP daemon has been started, you can use two commands to keep track of how the
ntpd daemon is working:
1) ntpq –p
This command queries the status of the ntpd daemon. Here is an example:
openSUSE:~ # ntpq –p
remote refid st t when poll reach delay offset jitter
==============================================================================
*LOCAL(0) .LOCL. 10 l 14 64 3 0.000 0.000 0.001
helium.constant 18.26.4.105 2 u 12 64 1 96.614 -31.777 0.001
The columns in the output include the following:
• remote
Specifies the hostname or IP address of the time provider.
• refid
Specifies the type of the reference source.
• st
Specifies the stratum of the time provider.
• when
Specifies the number of seconds since the last time poll.
• poll
Specifies the number of seconds between two time polls.
• reach
Displays whether or not the time server was reached in the last poll. Each
successful poll increments this field by 1.
• delay
Specifies the time (in milliseconds) that it took for the time provider to
respond to the request.
• offset
Specifies the time difference between the local system clock and the time
provider (in milliseconds).
•jitter
Specifies the size of time discrepancies (in milliseconds).
2) ntptrace
The ntptrace utility traces how the time consumer is receiving time from the
provider. It lists the time provider’s name, its stratum, and its time offset from the system
clock on the local system.
LX0-104 Exam Objectives (N)
System Time V
Configuring NTP
In order to use NTP to configure system time with an NTP time provider, you must first install
the ntpd daemon on your Linux system. You can use the
rpm –q ntp
command at the shell prompt to do this, like so:
openSUSE:~ # rpm -q ntp
ntp-4.2.6p5-15.5.1.i586
1) NTP is usually installed by default on most Linux systems. If it hasn’t been, you can use the
software package management utility of your choice to install it. Once this is done, you need to
next edit the
/etc/ntp.conf
file in a text editor. The first thing you need to do is ensure that the
following entries exist for the local clock, which is used if the time server is not available:
server 127.127.1.0 # local clock (LCL)
fudge 127.127.1.0 stratum 10 # LCL is unsynchronized
These directives tell the ntpd daemon to get time from the local clock in the event it can’t reach
any of the configured NTP time providers.
2) Next, you need to add entries to the file for network time providers you want your system to
sync time with. Here is the syntax:
server time_server_IP_address_or_DNS_name
You can specify the IP address or DNS name of any NTP time provider you want to use.
It could be any of the following:
• An NTP time provider on your network
• A public NTP time provider on the Internet
You can visit http://support.ntp.org/bin/view/Servers/WebHome to view a list of publicly available
NTP time providers on the Internet. If you wish, you can use an NTP pool time server. The
pool.ntp.org domain uses DNS round robin to make a random selection from a pool of time providers who have volunteered to be in the pool. That way, no one public NTP server is overloaded with
time synchronization requests. To use this, simply add the following server directive in
addition to the local clock server directive just discussed:
server pool.ntp.org
When you’re done, save your changes and then close the file. Before you actually start the
ntpd daemon, however, you need to do a quick, one-time synchronization with your NTP time
provider. The issue here is insane time. If your system time is already more than 17 minutes off
from the time on the NTP time provider, you must get the two systems within this time window
before NTP will work.
3) You can eliminate insane time issues by entering
ntpdate address_of_time_provider
at the shell prompt. This will perform an initial synchronization to get time close before you start the daemon. You may actually need to run the command multiple times if the times are really far apart between your system and the NTP time provider. The ntpd daemon must be stopped
before you run the ntpdate command!
Newer versions of NTP on newer Linux distributions also allow you to use the ntptimeset
option with the ntpd daemon itself to accomplish the same thing. Instead of specifying start,
stop, or restart with the daemon init script, you enter (on an system that uses init)
/etc/init.d/ntp ntptimeset
or
rcntp ntptimeset
at the shell prompt. When you do, a quick time sync takes place
with the time provider, as in this example:
ws1:/ # rcntp ntptimeset
Time synchronized with pool.ntp.org
4) Once this is done, you can then start the ntpd daemon using its init script in the appropriate
init script directory used by your distribution. If your system uses rc scripts, you can simply enter
rcntp start
at the shell prompt, like this:
ws1:/ # rcntp start
Time synchronized with pool.ntp.org
Starting network time protocol daemon (NTPD) done
5) You should configure the ntpd daemon to start every time the system boots using the
insserv ntp
command. After starting the daemon, you can check the ntp log file with the tail command
to verify that no errors occurred.
If your distribution uses systemd, you start and stop ntpd using the systemctl command. For
example, to start the ntpd daemon, you would enter
systemctl start ntp
at the shell prompt. You can verify that it started correctly by entering
systemctl status ntp
at the shell prompt.
LX0-104 Exam Objectives (N)
In order to use NTP to configure system time with an NTP time provider, you must first install
the ntpd daemon on your Linux system. You can use the
rpm –q ntp
command at the shell prompt to do this, like so:
openSUSE:~ # rpm -q ntp
ntp-4.2.6p5-15.5.1.i586
1) NTP is usually installed by default on most Linux systems. If it hasn’t been, you can use the
software package management utility of your choice to install it. Once this is done, you need to
next edit the
/etc/ntp.conf
file in a text editor. The first thing you need to do is ensure that the
following entries exist for the local clock, which is used if the time server is not available:
server 127.127.1.0 # local clock (LCL)
fudge 127.127.1.0 stratum 10 # LCL is unsynchronized
These directives tell the ntpd daemon to get time from the local clock in the event it can’t reach
any of the configured NTP time providers.
2) Next, you need to add entries to the file for network time providers you want your system to
sync time with. Here is the syntax:
server time_server_IP_address_or_DNS_name
You can specify the IP address or DNS name of any NTP time provider you want to use.
It could be any of the following:
• An NTP time provider on your network
• A public NTP time provider on the Internet
You can visit http://support.ntp.org/bin/view/Servers/WebHome to view a list of publicly available
NTP time providers on the Internet. If you wish, you can use an NTP pool time server. The
pool.ntp.org domain uses DNS round robin to make a random selection from a pool of time providers who have volunteered to be in the pool. That way, no one public NTP server is overloaded with
time synchronization requests. To use this, simply add the following server directive in
addition to the local clock server directive just discussed:
server pool.ntp.org
When you’re done, save your changes and then close the file. Before you actually start the
ntpd daemon, however, you need to do a quick, one-time synchronization with your NTP time
provider. The issue here is insane time. If your system time is already more than 17 minutes off
from the time on the NTP time provider, you must get the two systems within this time window
before NTP will work.
3) You can eliminate insane time issues by entering
ntpdate address_of_time_provider
at the shell prompt. This will perform an initial synchronization to get time close before you start the daemon. You may actually need to run the command multiple times if the times are really far apart between your system and the NTP time provider. The ntpd daemon must be stopped
before you run the ntpdate command!
Newer versions of NTP on newer Linux distributions also allow you to use the ntptimeset
option with the ntpd daemon itself to accomplish the same thing. Instead of specifying start,
stop, or restart with the daemon init script, you enter (on an system that uses init)
/etc/init.d/ntp ntptimeset
or
rcntp ntptimeset
at the shell prompt. When you do, a quick time sync takes place
with the time provider, as in this example:
ws1:/ # rcntp ntptimeset
Time synchronized with pool.ntp.org
4) Once this is done, you can then start the ntpd daemon using its init script in the appropriate
init script directory used by your distribution. If your system uses rc scripts, you can simply enter
rcntp start
at the shell prompt, like this:
ws1:/ # rcntp start
Time synchronized with pool.ntp.org
Starting network time protocol daemon (NTPD) done
5) You should configure the ntpd daemon to start every time the system boots using the
insserv ntp
command. After starting the daemon, you can check the ntp log file with the tail command
to verify that no errors occurred.
If your distribution uses systemd, you start and stop ntpd using the systemctl command. For
example, to start the ntpd daemon, you would enter
systemctl start ntp
at the shell prompt. You can verify that it started correctly by entering
systemctl status ntp
at the shell prompt.
LX0-104 Exam Objectives (N)
System Time IV
How NTP Works
You can use the ntpd daemon on Linux to synchronize time with another NTP time provider. In
fact, a system running ntpd can function as both a time consumer and a time provider
at the same time. The NTP protocol operates over IP port 123. The time consumer sends a time
synchronization request to the time provider on port 123. The time provider sends its time to the
consumer, and the system time on the consumer is adjusted according to the NTP algorithm.
Because NTP is designed to synchronize time across global networks, it
assumes all systems involved are configured to use UTP time.
Here are several key NTP concepts you need to be familiar with:
• Stratum
NTP uses the concept of stratum to define a hierarchy of NTP servers:
• Stratum 1
Stratum 1 time servers get their time from a reference time source, such
as the Naval atomic clock. (See tycho.usno.navy.mil for more information.)
• Stratum 2
Time servers that get their time from stratum 1 servers.
• Stratum 3
Time servers that get their time from stratum 2 servers.
• Stratum n
NTP servers can continue to a depth of 256 strata.
Although they are available on the Internet, you probably won’t be allowed access to a
Stratum 1 server. However, many Stratum 2 servers are publicly available. To reduce the
load on these public time sources, you should configure a very limited number of systems
on your internal network to sync time with the public time provider. In fact, many
organizations configure only a single Stratum 3 server on their network that gets its time
from a public Stratum 2 server on the Internet. They then configure all their internal
hosts to get their time from that server. On a larger network, you may need to configure
several Stratum 4 servers and configure them to get time from your Stratum 3 server and
then configure the rest of your network hosts to get time from the Stratum 4 servers.
This is shown in Figure 16-11.
• Stepping and slewing
The NTP protocol initially syncs time between the time
consumer and the time provider about once per minute. However, the interval increases
gradually to once every 17 minutes once time is closely synced between the provider and
consumer. Essentially, large adjustments occur relatively quickly, but then only small
adjustments are made across a longer time interval.
If the time difference between the provider and the consumer is small (less than
128 milliseconds), NTP adjusts the time on the consumer gradually. This is called
slewing.
If, on the other hand, the time difference between provider and consumer is
relatively large, the time adjustments are made more quickly on the consumer. This
is called stepping.
• Insane time
If the time difference between the provider and consumer is more than 17 minutes off, the
NTP daemon (ntpd) considers time to be “insane” and will not adjust it.
• Drift
NTP measures and corrects for incidental clock frequency errors (called
drift). It writes the current frequency value to the ntp.drift file in the /var/lib/ntp/drift/ directory.
If you stop and then restart the NTP daemon, it initializes the clock frequency using the
value in this file. This prevents ntpd from having to relearn the frequency error associated
with the system clock on your system. Here is a sample ntp.drift file:
openSUSE:/var/lib/ntp/drift # cat ./ntp.drift
0.000
• Jitter
Jitter is the estimated time difference between the consumer and the provider
since the last time poll.
LX0-104 Exam Objectives (N)
LX0-104 Exam Objectives (N)
You can use the ntpd daemon on Linux to synchronize time with another NTP time provider. In
fact, a system running ntpd can function as both a time consumer and a time provider
at the same time. The NTP protocol operates over IP port 123. The time consumer sends a time
synchronization request to the time provider on port 123. The time provider sends its time to the
consumer, and the system time on the consumer is adjusted according to the NTP algorithm.
Because NTP is designed to synchronize time across global networks, it
assumes all systems involved are configured to use UTP time.
Here are several key NTP concepts you need to be familiar with:
• Stratum
NTP uses the concept of stratum to define a hierarchy of NTP servers:
• Stratum 1
Stratum 1 time servers get their time from a reference time source, such
as the Naval atomic clock. (See tycho.usno.navy.mil for more information.)
• Stratum 2
Time servers that get their time from stratum 1 servers.
• Stratum 3
Time servers that get their time from stratum 2 servers.
• Stratum n
NTP servers can continue to a depth of 256 strata.
Although they are available on the Internet, you probably won’t be allowed access to a
Stratum 1 server. However, many Stratum 2 servers are publicly available. To reduce the
load on these public time sources, you should configure a very limited number of systems
on your internal network to sync time with the public time provider. In fact, many
organizations configure only a single Stratum 3 server on their network that gets its time
from a public Stratum 2 server on the Internet. They then configure all their internal
hosts to get their time from that server. On a larger network, you may need to configure
several Stratum 4 servers and configure them to get time from your Stratum 3 server and
then configure the rest of your network hosts to get time from the Stratum 4 servers.
This is shown in Figure 16-11.
• Stepping and slewing
The NTP protocol initially syncs time between the time
consumer and the time provider about once per minute. However, the interval increases
gradually to once every 17 minutes once time is closely synced between the provider and
consumer. Essentially, large adjustments occur relatively quickly, but then only small
adjustments are made across a longer time interval.
If the time difference between the provider and the consumer is small (less than
128 milliseconds), NTP adjusts the time on the consumer gradually. This is called
slewing.
If, on the other hand, the time difference between provider and consumer is
relatively large, the time adjustments are made more quickly on the consumer. This
is called stepping.
• Insane time
If the time difference between the provider and consumer is more than 17 minutes off, the
NTP daemon (ntpd) considers time to be “insane” and will not adjust it.
• Drift
NTP measures and corrects for incidental clock frequency errors (called
drift). It writes the current frequency value to the ntp.drift file in the /var/lib/ntp/drift/ directory.
If you stop and then restart the NTP daemon, it initializes the clock frequency using the
value in this file. This prevents ntpd from having to relearn the frequency error associated
with the system clock on your system. Here is a sample ntp.drift file:
openSUSE:/var/lib/ntp/drift # cat ./ntp.drift
0.000
• Jitter
Jitter is the estimated time difference between the consumer and the provider
since the last time poll.
LX0-104 Exam Objectives (N)
LX0-104 Exam Objectives (N)
System Time III
System Time III
Synchronizing Time with NTP
The key problem with using netdate in a cron job to keep time synchronized is the fact that netdate
adjusts the time abruptly. It doesn’t gradually adjust time to reach a point of synchronization.
Whatever time it is on the time server is the time the system time on the local system is set to.
In addition, netdate may adjust the time backward and forward, depending on how your local
system clock has drifted. This really messes up timestamps on your local files and can cause some
Linux services to completely freak out.
A better option for network time synchronization is to use the Network Time Protocol (NTP)
to sync time with a network time provider. NTP manages time in a much cleaner fashion than
netdate. NTP adjusts time in a much gentler manner. If there is a time differential between the
time provider and the time consumer (your local system), it adjusts time gradually in small increments
until time is eventually synchronized.
NTP is also widely supported by most operating systems. The netdate option only works
with the time service on a Linux/UNIX time provider. NTP, on the other hand, allows time to
be synchronized among systems in a heterogeneous network environment. It’s supported by the
following operating systems:
• Linux
• Windows
• OSX
• UNIX
NTP is a little more complex than netdate. Therefore, to implement NTP, you need to be
familiar with the following:
• How NTP works
• Configuring NTP
LX0-104 Exam Objectives (N)
Synchronizing Time with NTP
The key problem with using netdate in a cron job to keep time synchronized is the fact that netdate
adjusts the time abruptly. It doesn’t gradually adjust time to reach a point of synchronization.
Whatever time it is on the time server is the time the system time on the local system is set to.
In addition, netdate may adjust the time backward and forward, depending on how your local
system clock has drifted. This really messes up timestamps on your local files and can cause some
Linux services to completely freak out.
A better option for network time synchronization is to use the Network Time Protocol (NTP)
to sync time with a network time provider. NTP manages time in a much cleaner fashion than
netdate. NTP adjusts time in a much gentler manner. If there is a time differential between the
time provider and the time consumer (your local system), it adjusts time gradually in small increments
until time is eventually synchronized.
NTP is also widely supported by most operating systems. The netdate option only works
with the time service on a Linux/UNIX time provider. NTP, on the other hand, allows time to
be synchronized among systems in a heterogeneous network environment. It’s supported by the
following operating systems:
• Linux
• Windows
• OSX
• UNIX
NTP is a little more complex than netdate. Therefore, to implement NTP, you need to be
familiar with the following:
• How NTP works
• Configuring NTP
LX0-104 Exam Objectives (N)
System Time II
System Time II
Synchronizing Time with netdate
You can use the netdate command to synchronize time on the local system with the time on a time
server over the network. The syntax is
netdate time_server
where time_serveris the IP address or DNS name of another Linux system on the network that is running the time service, which is configured to listen on UDP port 37 by default for time requests. The time server could be an internal provider on your local LAN, or it could be an Internet-based time provider.
After syncing the system time with netdate, you may want to synchronize the system time with
your hardware clock using the
hwclock --systohc
command discussed earlier.
It’s important to note that netdate only syncs time once. If your system time drifts (and it will),
you may need to run netdate (and possibly hwclock --systohc) on a regular schedule to keep time
in sync. This can be done automatically using a cron job. However, it’s really not the best option.
LX0-104 Exam Objectives (N)
Synchronizing Time with netdate
You can use the netdate command to synchronize time on the local system with the time on a time
server over the network. The syntax is
netdate time_server
where time_serveris the IP address or DNS name of another Linux system on the network that is running the time service, which is configured to listen on UDP port 37 by default for time requests. The time server could be an internal provider on your local LAN, or it could be an Internet-based time provider.
After syncing the system time with netdate, you may want to synchronize the system time with
your hardware clock using the
hwclock --systohc
command discussed earlier.
It’s important to note that netdate only syncs time once. If your system time drifts (and it will),
you may need to run netdate (and possibly hwclock --systohc) on a regular schedule to keep time
in sync. This can be done automatically using a cron job. However, it’s really not the best option.
LX0-104 Exam Objectives (N)
System Time I
System Time I
Setting the Hardware Clock with hwclock
Recall from Chapter 5 that two time sources are used on a Linux system:
• Hardware clock
This clock is integrated into the CMOS chip on your Linux system’s
motherboard. It runs all the time, even when the system is powered off.
• System time
This clock runs via software inside the Linux kernel itself. It is driven by
an ISA timer interrupt. System time is measured as the number of seconds since 00:00:00
January 1, 1970, UTC.
The key thing to remember is that the hardware clock and the system time may not be
the same. When managing a Linux system, we are more concerned with the system time than the
time reported by the hardware clock. The role of the hardware clock is pretty basic. Its job
is to keep time when the system is powered off. The system time is synchronized to the hardware
clock time when the Linux operating system starts. After booting, Linux only uses system time.
The hardware clock is ignored.
To manage the hardware clock on your system, you can use the
hwclock
command at the shell prompt. It can do the following:
• Display the current time.
• Set the hardware clock time.
• Synchronize the hardware clock to the system time.
• Synchronize the system time to the hardware clock.
You can use the options shown in Table 16-3 with hwclock on most Linux distributions.
As you can see, the scope of hwclock’s functionality is limited to the local computer system. On
a network, you may need to ensure that the system time on your Linux systems is synchronized.
[options shown in Table 16-3 with hwclock, p 609]
LX0-104 Exam Objectives (N)
Setting the Hardware Clock with hwclock
Recall from Chapter 5 that two time sources are used on a Linux system:
• Hardware clock
This clock is integrated into the CMOS chip on your Linux system’s
motherboard. It runs all the time, even when the system is powered off.
• System time
This clock runs via software inside the Linux kernel itself. It is driven by
an ISA timer interrupt. System time is measured as the number of seconds since 00:00:00
January 1, 1970, UTC.
The key thing to remember is that the hardware clock and the system time may not be
the same. When managing a Linux system, we are more concerned with the system time than the
time reported by the hardware clock. The role of the hardware clock is pretty basic. Its job
is to keep time when the system is powered off. The system time is synchronized to the hardware
clock time when the Linux operating system starts. After booting, Linux only uses system time.
The hardware clock is ignored.
To manage the hardware clock on your system, you can use the
hwclock
command at the shell prompt. It can do the following:
• Display the current time.
• Set the hardware clock time.
• Synchronize the hardware clock to the system time.
• Synchronize the system time to the hardware clock.
You can use the options shown in Table 16-3 with hwclock on most Linux distributions.
As you can see, the scope of hwclock’s functionality is limited to the local computer system. On
a network, you may need to ensure that the system time on your Linux systems is synchronized.
[options shown in Table 16-3 with hwclock, p 609]
LX0-104 Exam Objectives (N)
Maintaining System Time
Maintaining System Time
Recall that when you initially set up your Linux system, you were prompted to configure your
system time and your time zone. You may have not considered these settings as terribly critical to
the overall functioning of the system. I work with many system administrators who feel they same
way. The time on their systems is always out of whack and it drives me nuts!
However, when you’re working with Linux, it is actually quite important that you maintain
the correct system time, especially if the system is providing network services. You need to ensure that file timestamps are accurate. If your system is participating in some type of directory service or is a database server, then maintaining the correct system time is absolutely critical. For example, each change submitted to a database server from client systems must have an accurate timestamp. Image what problems could arise if database modifications get applied out of sequence because the timestamps are inaccurate. The integrity of your data is toast!
In Chapter 5, we discussed how to set your time zone when we looked at managing locale settings.
In this chapter, we’ll address the following topics:
• Setting the hardware clock with hwclock
• Synchronizing time with netdate
• Synchronizing time with NTP
LX0-104 Exam Objectives (N)
Recall that when you initially set up your Linux system, you were prompted to configure your
system time and your time zone. You may have not considered these settings as terribly critical to
the overall functioning of the system. I work with many system administrators who feel they same
way. The time on their systems is always out of whack and it drives me nuts!
However, when you’re working with Linux, it is actually quite important that you maintain
the correct system time, especially if the system is providing network services. You need to ensure that file timestamps are accurate. If your system is participating in some type of directory service or is a database server, then maintaining the correct system time is absolutely critical. For example, each change submitted to a database server from client systems must have an accurate timestamp. Image what problems could arise if database modifications get applied out of sequence because the timestamps are inaccurate. The integrity of your data is toast!
In Chapter 5, we discussed how to set your time zone when we looked at managing locale settings.
In this chapter, we’ll address the following topics:
• Setting the hardware clock with hwclock
• Synchronizing time with netdate
• Synchronizing time with NTP
LX0-104 Exam Objectives (N)
Time Zone Settings II
How Time Works on Linux
Before managing time zones on Linux, you need to understand how time works on Linux. The
first thing you need to understand is that there are two main clocks in a Linux system:
• Hardware clock
This clock runs independently all the time, even when the system is
powered off. The hardware clock is called by a variety of names, including the Real Time
Clock (RTC) or the BIOS/CMOS clock.
You can use the hwclock command at the shell prompt to set the time in the hardware clock.
• System time
This clock runs via software inside the Linux kernel itself. It is driven by
an ISA timer interrupt. System time is measured as the number of seconds since 00:00:00
January 1, 1970 UTC.
The key thing to remember is that the hardware clock and the system time may not be the
same. When managing a Linux system, we are more concerned with the system time than the
time reported by the hardware clock. The role of the hardware clock is pretty basic. Its job is to
keep time when the system is powered off. The system time is synchronized to the hardware clock
time when the Linux operating system starts. After booting, Linux only uses system time. The
hardware clock is ignored.
When setting the time on your hardware clock, you should set it to one of the following:
• Universal Time Coordinated (UTC)
UTC is the standard by which the world regulates time. UTC is the current mean solar time at the
Royal Observatory in Greenwich, London, in England. Thus, UTC is also referred to as
Greenwich Mean Time (GMT).
Your local time is determined by adding or subtracting one hour to or from
UTC for each time zone you are away from UTC. For example, I live seven time zones
away from Greenwich, so my time is UTC –7. Therefore, at 10:58 a.m. my local time,
it’s 5:58 p.m. UTC.
If your hardware clock is set to UTC instead of the local time, you
need to set the
HWCLOCK directive
in the
/etc/sysconfig/clock
file to
–u.
Your Linux system will automatically calculate daylight savings time offsets according to your local time zone.
For Linux systems, it is actually preferred that you set your hardware
clock to UTC instead of local time.
• Local time
The hardware clock in most systems you will encounter will be set to local
time by default. If this is the case, the
HWCLOCK directive
in the
/etc/sysconfig/clock
file will be set to
--localtime
Setting your hardware clock to UTC is the preferred option when working with Linux systems.
Using UTC makes calculating time zone differences much easier. In fact, if you install certain
groupware applications on your Linux system, you may be required to set your hardware clock to
UTC because it makes it easier to coordinate time stamps among a large number of computers
located in different time zones.
LX0-104 Exam Objectives (M)
Before managing time zones on Linux, you need to understand how time works on Linux. The
first thing you need to understand is that there are two main clocks in a Linux system:
• Hardware clock
This clock runs independently all the time, even when the system is
powered off. The hardware clock is called by a variety of names, including the Real Time
Clock (RTC) or the BIOS/CMOS clock.
You can use the hwclock command at the shell prompt to set the time in the hardware clock.
• System time
This clock runs via software inside the Linux kernel itself. It is driven by
an ISA timer interrupt. System time is measured as the number of seconds since 00:00:00
January 1, 1970 UTC.
The key thing to remember is that the hardware clock and the system time may not be the
same. When managing a Linux system, we are more concerned with the system time than the
time reported by the hardware clock. The role of the hardware clock is pretty basic. Its job is to
keep time when the system is powered off. The system time is synchronized to the hardware clock
time when the Linux operating system starts. After booting, Linux only uses system time. The
hardware clock is ignored.
When setting the time on your hardware clock, you should set it to one of the following:
• Universal Time Coordinated (UTC)
UTC is the standard by which the world regulates time. UTC is the current mean solar time at the
Royal Observatory in Greenwich, London, in England. Thus, UTC is also referred to as
Greenwich Mean Time (GMT).
Your local time is determined by adding or subtracting one hour to or from
UTC for each time zone you are away from UTC. For example, I live seven time zones
away from Greenwich, so my time is UTC –7. Therefore, at 10:58 a.m. my local time,
it’s 5:58 p.m. UTC.
If your hardware clock is set to UTC instead of the local time, you
need to set the
HWCLOCK directive
in the
/etc/sysconfig/clock
file to
–u.
Your Linux system will automatically calculate daylight savings time offsets according to your local time zone.
For Linux systems, it is actually preferred that you set your hardware
clock to UTC instead of local time.
• Local time
The hardware clock in most systems you will encounter will be set to local
time by default. If this is the case, the
HWCLOCK directive
in the
/etc/sysconfig/clock
file will be set to
--localtime
Setting your hardware clock to UTC is the preferred option when working with Linux systems.
Using UTC makes calculating time zone differences much easier. In fact, if you install certain
groupware applications on your Linux system, you may be required to set your hardware clock to
UTC because it makes it easier to coordinate time stamps among a large number of computers
located in different time zones.
LX0-104 Exam Objectives (M)
Subscribe to:
Posts (Atom)