LPI Linux Certification in a Nutshell (54 page)

hwclock

hwclock –-show
hwclock --systohc
hwclock –-hctosys
hwclock --adjust
hwclock --version

Query and/or set the hardware clock.

Query the system’s hardware clock:

#
/sbin/hwclock --show
Sat 12 Sep 2009 12:49:43 PM CDT  -0.216537 seconds

Set the hardware clock to the current value of the system
clock:

#
/sbin/hwclock –-systohc

All time values in the hardware clock are stored as the number
of seconds since January 1, 1970. This number is then converted to
the output format desired. Time is represented as either
Coordinated Universal Time (UTC) or local time. UTC is
a universal time standard that is the same across all
time zones. Local time is simply UTC combined with
either a positive or negative offset to reflect the current time
zone. For example, in the United States, the Central Time Zone is
actually UTC-6 (six hours behind Coordinated Universal Time).

As a system administrator, you have the option of setting your
hardware clock to either UTC or your own local time. Some
administrators prefer to use UTC for this, and then reflect their
current time zone in the system software. The
hwclock
command allows you to indicate how your
hardware clock is set. Compare the output of these two
commands:

#
/sbin/hwclock –show --localtime
Sat Sep 12 13:33:35 2009  -0.766111 seconds
#
/sbin/hwclock –-show --utc
Sat Sep 12 08:33:37 2009  -0.048881 seconds

Telling
hwclock
that our hardware clock
was set to UTC time resulted in a different answer when we asked to
show the time.

• All logfiles are centralized, either in one directory or on one
  server.
  

• The client/server nature of
  syslogd
  allows
  for machines to log events to a centralized log server for easier
  monitoring and reporting.
  

• Syslogd
  allows multiple processes to write
  to the same logfile, while avoiding file-locking issues.
  

The behavior of
syslogd
is controlled
by its configuration file,
/etc/syslog.conf
. This
text file contains lines indicating what is to be logged and where. Each
line contains directives in this form:

facility.level action

The directives are defined as follows:

For example, if you wanted to create a separate logfile for
activity reported by the scripts you write, you might include a line
like this in
/etc/syslog.conf
:

# Define a new log file for the local5 facility
local5.*                           /var/log/local5

You could then use the
logger
utility to
write messages to the facility from your shell script
(
syslogd
must be restarted or signaled to
reinitialize before the new logfile is created):

$
logger -p local5.info "Script terminated normally"

The message “Script terminated normally” would be placed into
/var/log/local5
, along with a timestamp and the
hostname that sent the message.
Example 16-2
contains an
example
/etc/syslog.conf
file.

# Log everything except mail & authpriv of level info
# or higher to messages.
*.info;mail.none;authpriv.none     /var/log/messages
# The authpriv file has restricted access.
authpriv.*                         /var/log/secure
# Log all the mail messages in one place.
mail.*                             /var/log/maillog
# Everybody gets emergency messages.
*.emerg                            *
# Save boot messages also to boot.log
local7.*                           /var/log/boot.log

If you examine this
syslog.conf
file, you’ll
see that nearly all system messages are sent to the
/var/log/messages
file via the
*.info
message selector. In this case, the
asterisk directs
syslogd
to send messages from all
facilities except
mail
and
authpriv
, which are excluded using the special
none
level. The
/var/log/messages
file is the default system
message destination, and you will consult it frequently for information
on processes running (or failing to run) and other events on your
system. In this example, the low severity level of
info
is used for the
messages
file, which logs all but debugging
messages. On heavily loaded servers, this may result in an unwieldy file
size due to message volume. Depending upon your available disk space,
you may choose to save less information by raising the level for the
messages
file.

The
syslogd
server keeps the file handles
open for all files defined in
/etc/
sys
log.conf
.
This means that the only process that can write to these files is
syslogd
. Do not configure your programs to write
directly to these files! Instead, call a program such as
logger
, or use one of the many syslog API
interfaces available for your language of choice.

The syslog service is actually made up of two processes,
syslogd
and
klogd
.
Syslogd
is used to log events from user process,
whereas
klogd
is used to log events from kernel
processes. They work in tandem and use the same configuration file, so
you really just need to make sure they are both running:

$
ps ax | egrep -i "(syslogd|klogd)"
2078 ?
Ss   0:04 syslogd -m 0
2081 ?
Ss   0:00 klogd -x

Syslogd
also has the ability to log
messages across the network. If a syslogd process is started with the
-r
option, it will listen on the network for
incoming
syslogd
messages. By default,
syslogd
uses UDP port 514 for this communication. A
common practice is to set up one master logging server that receives all
syslogd
messages from all clients. On the client
side, you would configure the local
syslogd
service
to log events locally, and to log everything to the master logging
server. This would be accomplished by adding the following line to the
example
syslog.conf
file shown in
Example 16-2
:

*.*      @10.0.0.1

This means that messages matching all facilities and levels should
be sent to the IP address 10.0.0.1.

You can determine whether a
syslogd
server is
listening for remote log entries by running
netstat
:

#
netstat -anp | grep -i ":514"
udp        0      0 0.0.0.0:514             0.0.0.0:*           26645/syslogd

Most distributions will install a default
syslog
configuration for you, including logging to
messages
and other logfiles in
/var/log
. To prevent any of these files from
growing unattended to extreme sizes, a logfile rotation scheme should be
installed as well. The
cron
system issues commands on a
regular basis (usually once per day) to establish new logfiles; the old
files are renamed with numeric suffixes. With this kind of rotation,
yesterday’s
/var/log/messages
file becomes today’s
/var/log/
messages.1
, and a new
/var/log/messages
file is created. The rotation is
configured with a maximum number of files to keep, and the oldest
logfiles are deleted when the rotation is run.

The utility that establishes the rotation is
logrotate
. This privileged command is
configured using one or more files, which are specified as arguments to
the
logrotate
command. These configuration files
can contain directives to include other files as well. The default
configuration file is
/etc/logrotate.conf
.
Example 16-3
depicts a sample
logrotate.conf
file.

# global options
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
# send errors to root
errors root
# create new (empty) log files after rotating old ones
create
# compress log files
compress
# specific files
/var/log/wtmp {
monthly
create 0664 root utmp
rotate 1
}
/var/log/messages {
postrotate
/usr/bin/killall -HUP syslogd
endscript
}

This example specifies rotations for two files,
/var/log/wtmp
and
/var/log/messages
. Your configuration will be much
more complete, automatically rotating all logfiles on your system. A
complete understanding of
logrotate
configuration
is not necessary for LPIC Level 1 Exams, but you must be familiar with
the concepts involved. See the
logrotate
manpages
for more information.

You can learn a lot about the activity of your system by reviewing
the logfiles it creates. At times, it will be necessary to debug
problems using logged information. Since most of the logfiles are plain
text, it is very easy to review their contents with tools such as
tail
,
less
, and
grep
.

Syslogd
stores the messages it creates with
the following information, separated by (but also including)
spaces:

Typical messages will look like this:

Aug  3 18:45:16 moya kernel: Partition check:
Aug  3 18:45:16 moya kernel: sda: sda1 sda2 sda3 < sda5 sda6 sda7 \
sda8 sda9 sda10 > sda4
Aug  3 18:45:16 moya kernel: SCSI device sdb: 195369520 512-byte \
hdwr sectors (100029 MB)
Aug  3 18:45:16 moya kernel:  sdb: sdb1
Aug  3 18:45:16 moya kernel: Journalled Block Device driver loaded
Aug  3 18:45:16 moya kernel: kjournald starting.  Commit interval 5 seconds
Aug  3 18:45:16 moya kernel: EXT3-fs: mounted filesystem with ordered data
mode.
Aug  3 18:45:16 moya kernel: Freeing unused kernel memory: 116k freed
Aug  3 18:45:16 moya kernel: Adding Swap: 1044216k swap-space (priority -1)

In this case,
moya
is the
hostname, and the messages are coming from the kernel. At any time, you
can review the entire contents of your logfiles using
less
:

#
less /var/log/messages

You can then page through the file. This is a good way to become
familiar with the types of messages you’ll see on your system. To
actively monitor the output to your messages file, you could use
tail
:

#
tail -f /var/log/messages

This might be useful, for example, to watch system activity as an
Internet connection is established via modem. To look specifically for
messages regarding your mouse, you might use
grep
:

#
grep '[Mm]ouse' /var/log/messages
Dec  8 00:15:28 smp kernel: Detected PS/2 Mouse Port.
Dec  8 10:55:02 smp gpm: Shutting down gpm mouse services:

Often, if you are using
grep
to look for a
particular item you expect to find in
/var/log/messages
, you will need to search all of
the rotated files with a wildcard. For example, to look for all messages
from
sendmail
, you can issue a command like
this:

#
grep 'sendmail:' /var/log/messages*

Or, if you’ve enabled compression for the rotated logfiles:

#
zgrep 'sendmail:' /var/log/messages*

When you note problems in logfiles, look at the hostname and
sender of the message first, and then the message text. In many cases,
you will be able to determine what is wrong from the message. Sometimes
the messages are only clues, so a broader review of your logs may be
necessary. In this case, it may be helpful to temporarily turn on more
messaging by using the debug level in
/etc/syslog.conf
to help yield additional
information that can lead you to the problem.