ADMIN+Magazine+Sample+PDF

Daemon Monitoring
Nuts and Bolts
Figure 1: After starting, the script outputs the log at the console: availability,
error, restart, database running.
Almost all known databases include
a client program for the shell – for
example, mysql for MySQL or psql for
PostgreSQL. Alternatively, you can
use ODBC to access the database in
your scripted monitoring, such as the
isql tool provided by the Unix ODBC
project.
For ease of access, you might need to
set up a (non-privileged) user, a database,
and a table for the test query
on the database server. If you choose
the ODBC option, you also need a
.odbc.ini file with the right access
credentials.
The psql shell client for the Postgres
database also poses the problem of
non-standard exit codes. 1 stands for
an error in the query, although the
connect attempt has been successful;
2 indicates a connection error.
A connection test with psql would
look like this:
psql ‐U User ‐d Database ‐c U
"select * from test_table;"
For ODBC access, you would need to
pipe the SQL query to the client:
echo "select * from test_table;" | U
isql ODBC_data_source user
For the cups printer daemon, lpq
gives you a simple method of checking
whether the daemon is alive. If
you need to check access to individual
printers, you additionally need
to provide the print queue name and
then grep the exit code. To make sure
the exit code complies with this behavior,
Grep checks the output that
you receive if the printer is active:
lpq ‐Pprinter | grep ‐q U
"printer is ready"
To match the output from lpq, you
need to modify the search string for
grep.
The ping command
checks
network connections.
The
exit error codes
differ, depending
on your operating
system. The
FreeBSD ping
uses 2, the Linux
ping uses 1.
The number of test packets is restricted
by the ‐c packets option;
this improves the script run time and
avoids unnecessary network traffic. If
you use the IP address as the target,
you avoid the risk of false positives
from buggy name resolution.
ping ‐c1 ip_address
Sensor scripts can obviously be extended
to cover many other system
parameters, such as disk space usage
(df), logged in users (who), and much,
much more.
If an error or threshold value infringement
occurs, the script can use this
information to generate a message
and notify the system administrator.
The message text should include the
hostname, date, and time. Messages
can be stored in a file to which the
administrator has permanent access.
To allow this to happen, you simply
have to display the logfile in a terminal
and use tail ‐f, but other forms
of communication are also possible –
texting, for example.
If the shell script has the correct
privileges, it can become involved
and restart a daemon, remove block
files, or even reboot the whole system.
Because you should avoid running
this kind of script as root, you
can instead set up special users and
groups to own the script and the
process (which is the case with many
daemons).
Database Restart
The sample script in Listing 1 monitors
an active database instance and
notifies the administrator if the database
happens to fail and then is
successfully restarted (Figure 1). If
it can’t start the daemon, it waits
for the administrator to step in and
handle the situation.
Printer Restart
The second sample script relates to
the printing service. The one shown
here is taken from a production example,
in which the cupsd server has
an unknown problem with a network
printer. The printer was disabled time
and time again, causing no end of
frustration to users and unnecessary
work for the system admins. The shell
script shown in Listing 2 doesn’t
output messages; instead, it simply
restarts the service. Either run these
scripts manually (for a temporary fix
or quick check) or as RC scripts.
Conclusions
Administrators don’t need a complex
monitoring framework that covers
every aspect of the environment and
has a multi-week learning curve.
With some scripting know-how, you
can easily create your own shell
scripts to monitor server daemon processes
and restart them autonomously
if so desired. The use of shell scripts
to monitor daemons and other system
functions is by no means restricted to
small embedded systems. With scripts
tailored to match your requirements,
you can establish your own troubleshooting
arsenal.
n
The Author
Harald Zisler has worked with Unix-flavored
operating systems since the early 1990s.
Listing 2: CUPS Monitoring
01 #! /bin/sh
02
03 while true
04 do
05
06 lpq ‐Plp | grep ‐q "lp is ready"
07
08 if [ $? ‐gt 0 ]
09 then
10 cupsenable lp
11 fi
12
13 sleep 15
14
15 done
www.admin-magazine.com
Admin 01
93