UNIX Hints & Hacks

ContentsIndex

Chapter 4: System Monitoring

 

Previous ChapterNext Chapter

Sections in this Chapter:

   

4.1 Monitoring at Boot Time

 

4.5 Mail a Process

 

4.9 Monitoring with ping

 

4.2 Starting with a Fresh Install

 

4.6 Watching the Disk Space

 

4.10 Monitoring Core Files

 

 

4.3 Monitor with tail

 

4.7 Find the Disk Hog

 

4.11 Monitoring Crash Files

 

 

4.4 Cut the Log in Half

 

4.8 Watching by grepping the Difference

 

4.12 Remember Daylight Savings Time

 

 

 

4.13 Checking the Time

4.13.1 Description

4.13.1 Description

A quick way to check and verify the time on remote machines over the network.

Example

Flavors: AT&T, BSD

Shells: All

Syntax:

telnet host [port]

The time of any machine can be checked simply by issuing a Telnet session to the port 13. This port is known as the daytime port. It works like this:

% telnet rocket 13
Trying 209.10.11.102
Connected to rocket.
Escape character is '^]'.
Sun Oct 18 11:45:02 1998
Connection closed by foreign host.

For this to work, a couple of things need to be set up on the remote machine you are monitoring the time on. The /etc/services file needs to have a TCP and UDP entry made for daytime at port 13.

# vi /etc/services
daytime 13/tcp daytime 13/udp

The /etc/inetd.conf file needs to be edited so that the daemon wakes up and a connection can be established to port 13.

# vi /etc/inetd.conf
daytime stream tcp nowait root internal daytime dgram udp wait root internal

When /etc/inetd.conf is edited, don't forget to get the process ID of inetd and restart the daemon.

# ps -e | grep inetd
  199 ?     0:00 inetd
# kill -HUP 199

Now when Telnet is initiated from a remote system you should see something similar to

% telnet xinu 13
Trying 209.10.11.104
Connected to xinu.
Escape character is '^]'.
Sun Oct 18 11:52:13 1998
Connection closed by foreign host.

There are a couple of ways to expand this to a script and check the time of multiple machines in your environment. The quick and dirty way is to write a script called timecheck:

% vi timecheck
telnet rocket 13 telnet xinu 13 telnet ugu 13

Line 1: Telnet to the first machine and get the time.

Line 2: Telnet to the second machine and get the time.

Line 3: Telnet to the third machine and get the time.

And so on...

The result is a bit messy looking with the output having the following appearance:

% ./timecheck
Trying 209.10.11.102...
Connected to rocket.
Escape character is '^]'.
Sun Oct 18 14:07:08 1998
Connection closed by foreign host.
Trying 209.10.11.104...
Connected to xinu.
Escape character is '^]'.
Sun Oct 18 14:07:08 1998
Connection closed by foreign host.
Trying 209.10.11.105...
Connected to ugu.
Escape character is '^]'.
Sun Oct 18 14:07:10 1998
Connection closed by foreign host.

To clean up the output, the script could be rewritten to get rid of the extra output and print the time information that you are interested in.

% vi timecheck2
rocket=`telnet rocket 13 | tail -1` xinu=`telnet xinu 13 | tail -1` ugu=`telnet ugu 13 | tail -1` echo echo "rocket: $rocket" echo "xinu: $xinu" echo "ugu: $ugu"

Lines 1-3: Get the time for the remote host and store it into special variables.

Lines 4-6: Display the hostname and the current time of the system from the variables that the times were put into.

% ./timecheck2
Connection closed by foreign host.
Connection closed by foreign host.
Connection closed by foreign host.
Connection closed by foreign host.
rocket: Sun Oct 18 14:20:11 1998 xinu: Sun Oct 18 14:20:11 1998 ugu: Sun Oct 18 14:20:12 1998

Due to the way that Telnet and the telnetd daemon handle closing a connection to a foreign host, the message "Connection closed by foreign host" cannot be extracted from the tail. This is why the Telnet commands were executed, passed into a variable, and echoed out later.

Reason

There is more than one reason why a system clock can be set incorrectly. These range from a system staying up for long periods of time without rebooting to replacing hardware in a system. The time should be checked regularly.

Real World Experience

Programmers and developers are strictly dependent on the system's internal clock being correct for developing applications. It has been shown that even if systems are locked to one designated time server, the systems that are slaves to the time server can eventually provide false dates. When it is so critical to have the system clock be right, the extra step should be well worth it.

Other Resources

Man pages:

inetd, services, telnet

UNIX Hints & Hacks

ContentsIndex

Chapter 4: System Monitoring

 

Previous ChapterNext Chapter

Sections in this Chapter:

   

4.1 Monitoring at Boot Time

 

4.5 Mail a Process

 

4.9 Monitoring with ping

 

4.2 Starting with a Fresh Install

 

4.6 Watching the Disk Space

 

4.10 Monitoring Core Files

 

 

4.3 Monitor with tail

 

4.7 Find the Disk Hog

 

4.11 Monitoring Crash Files

 

 

4.4 Cut the Log in Half

 

4.8 Watching by grepping the Difference

 

4.12 Remember Daylight Savings Time

 

 

 

© Copyright Macmillan USA. All rights reserved.