NAME¶

ps-watcher - monitors various processes based on ps-like information.

SYNOPSIS¶

ps-watcher [options...]
["--config"] config-file

DESCRIPTION¶

Periodically a list of processes obtained via "ps". More precisely each item in the list contains the process name (just what's listed in the "cmd" field, not the full command and arguments) and its process id (pid). A configuration file specifies a list of Perl regular-expression patterns to match the processes against. For each match, a Perl expression specified for that pattern is evaluated. The evaluated expression can refer to variables which are set by ps and pertain to the matched process(es), for example the amount memory consumed by the process, or the total elapsed time. Some other variables are set by the program, such as the number of times the process is running. If the Perl expression for a matched pattern evaluates true, then an action can be run such as killing the program, restarting it, or mailing an alert, or running some arbitrary Perl code.

Some things you might want to watch a daemon or process for:

• check that it is running (hasn't died)
• ensure it is not running too many times
• isn't consuming too much memory (perhaps a memory leak), or I/O

Some actions you might want to take:

• restart a process
• kill off rampant processes
• send an alert about any of the conditions listed above

Depending on options specfied, this program can be run as a daemon, run once (which is suitable as a "cron" job), or run not as a daemon but still continuously (which may be handy in testing the program or your configuration).

CONFIGURATION FILE FORMAT¶

The format of a configuration file is a series of fully qualified filenames enclosed in square brackets followed by a number of parameter lines. Each parameter line has a parameter name followed by an "equal" sign and finally value. That is:

 # This is a comment line
 ; So is this.
 [process-pattern1]
  parameter1 = value1
  parameter2 = value2
 [process-pattern2]
  parameter1 = value3
  parameter2 = value4

Comments start with # or ; and take effect to the end of the line.

This should be familiar to those who have worked with text-readible Microsoft ".INI" files.

Note process patterns, (process-pattern1 and process-pattern2 above) must be unique. If there are times when you may want to refer to the same process, one can be creative to make these unique. e.g. cron and [c]ron which refer to the same process even though they appear to be different.

As quoted directly from the Config::IniFiles documentation:

Multiline or multivalued fields may also be defined ala UNIX "here document" syntax:

  Parameter=<<EOT
  value/line 1
  value/line 2
  EOT

You may use any string you want in place of "EOT". Note that what follows the "<<" and what appears at the end of the text must match exactly, including any trailing whitespace.

There are two special "process patterns": $PROLOG and $EPILOG, the former should appear first and the latter last.

You can put perl code to initialize variables here and do cleanup actions in these sections using "perl-action."

A description of parameters names, their meanings and potential values follows.

trigger

This parameter specifies the condition on which a process action is fired. The condition is evaluated with Perl eval() and should therefore return something which is equivalent to "true" in a Perl expression.

If no trigger is given in a section, true or 1 is assumed and the action is unconditionally triggered.

Example:

  # Match if httpd has not spawned enough (<4) times. NFS and databases
  # daemons typically spawn child processes.  Since the program
  # matches against the command names, not commands and arguments,
  # something like: ps -ef | grep httpd won't match the below.
  # If you want to match against the command with arguments, see
  # the example with $args below.
  [httpd$]
  trigger = $count <= 4
    

occurs

This parameter specifies how many times an action should be performed on processes matching the section trigger. Acceptable values are "every", "first", "first-trigger", and "none".

Setting the occurs value to "none" causes the the trigger to be evaluated when there are no matching processes. Although one might think "$count == 0" in the action expression would do the same thing, currently as coded this does not work.

Setting the occurs value to "first" causes the process-pattern rule to be finished after handling the first rule that matches, whether or not the trigger evaluated to true.

Setting the occurs value to "first-trigger" causes the process-pattern rule to be finished after handling the first rule that matches and the trigger evaluates to true.

If the item parameter is not specified, "first" is assumed.

Examples:

  [.]
  occurs = first
  action = echo "You have $count processes running"
  # Note in the above since there is no trigger specified,
  #   occurs = first
  # is the same thing as 
  #   occurs = first-trigger
  [.?]
  trigger = $vsz > 1000
  occurs  = every
  action  = echo "Large program $command matches $ps_pat: $vsz KB"
  # Fire if /usr/sbin/syslogd is not running.
  # Since the program matches against the command names, not commands and
  # arguments, something like: 
  #   ps -ef | grep /usr/sbin/syslogd
  # won't match the below.
  [(/usr/sbin/)?syslogd]
  occurs = none
  action = /etc/init.d/syslogd start
    

action

This specifies the action, a command that gets run by the system shell, when the trigger condition is evaluated to be true.

Example:

 action = /etc/init.d/market_loader.init restart
    

perl-action

This specifies Perl statements to be eval'd. This can be especially useful in conjunction with $PROLOG and $EPILOG sections to make tests across collections of process and do things which ps-watcher would otherwise not be able to do.

Example:

  # A Perl variable initialization.
  # Since ps-watcher runs as a daemon it's a good idea
  # to (re)initialize variables before each run.
  [$PROLOG]
    perl-action = $root_procs=0;
  # Keep track of how many root processes we are running
  [.*]
    perl-action = $root_procs++ if $uid == 0
    occurs  = every
  # Show this count.
  [$EPILOG]
    action  = echo "I counted $root_procs root processes"
    

 uid euid ruid gid egid rgid alarm blocked bsdtime c caught
cputime drs dsiz egroup eip esp etime euser f fgid
fgroup flag flags fname fsgid fsgroup fsuid fsuser fuid fuser
group ignored intpri lim longtname m_drs m_trs maj_flt majflt
min_flt  minflt ni nice nwchan opri pagein pcpu pending pgid pgrp
pmem ppid pri rgroup rss rssize rsz ruser s sess session
sgi_p sgi_rss sgid sgroup sid sig sig_block sig_catch sig_ignore
sig_pend sigcatch sigignore sigmask stackp start start_stack start_time
stat state stime suid suser svgid svgroup svuid svuser sz time timeout
tmout tname tpgid trs trss tsiz tt tty tty4 tty8 uid_hack uname
user vsize vsz wchan

  use constant MINS   => 60;
  use constant HOURS  => 60*60;
  use constant DAYS   => HOURS * 24;

  # Which processes have been running for more than 3 hours?
  # Also note use of builtin-function elapsed2secs, variable $etime
  # and builtin-function HOURS
  [.]
    trigger = elapsed2secs('$etime') > 1*DAYS
    action  = echo "$command has been running more than 1 day ($etime)"
    occurs  = every

EXAMPLE CONFIGURATION¶

  # Comments start with # or ; and go to the end of the line.
  # The format for each entry is in Microsoft .INI form:
  # [process-pattern]
  # trigger = perl-expression
  # action  = program-and-arguments-to-run
  [httpd$]
    trigger = $count < 4
    action  = echo "$trigger fired -- You have $count httpd sessions."
  [.]
  trigger = $vsz > 10
  action  = echo "Looks like you have a big $command program: $vsz KB"
  # Unfortunately we have use a different pattern below. (Here we use
  # ".?" instead of ".".) In effect the the two patterns mean
  # test every process.
  [.?]
    trigger = elapsed2secs('$etime') > 2*MINS && $pcpu > 40
    occurs  = every
    action  = <<EOT
     echo "$command used $pcpu% CPU for the last $etime seconds" | /bin/mail root
     kill -TERM $pid
  EOT
  # Scripts don't show as the script name as the command name on some
  # operating systems.  Rather the name of the interpreter is listed
  # (e.g. bash or perl) Here's how you can match against a script.
  # BSD/OS is an exception: it does give the script name rather than
  # the interpreter name.
  [/usr/bin/perl]
    trigger = \$args !~ /ps-watcher/
    occurs  = every
    action  = echo "***found perl program ${pid}:\n $args"

Using $PROLOG for getting non-ps information¶

Here is an example to show how to use ps-watcher to do something not really possible from ps: check to see if a port is active. We make use of lsof to check port 3333 and the $PROLOG make sure it runs.

  [$PROLOG]
    occurs  = first
    trigger = { \$x=`lsof -i :3333 >/dev/null 2>&1`; \$? >> 8 }
    action  = <<EOT
    put-your-favorite-command-here arg1 arg2 ...
  EOT

SECURITY CONSIDERATIONS¶

Any daemon such as this one which is sufficiently flexible is a security risk. The configuration file allows arbitrary commands to be run. In particular if this daemon is run as root and the configuration file is not protected so that it can't be modified, a bad person could have their programs run as root.

There's nothing in the ps command or ps-watcher, that requires one to run this daemon as root.

So as with all daemons, one needs to take usual security precautions that a careful sysadmin/maintainer of a computer would. If you can run any daemon as an unprivileged user (or with no privileges), do it! If not, set the permissions on the configuration file and the directory it lives in.

This program can also run chrooted and there is a "--path" option that is available which can be used to set the executable search path. All commands used by ps-watcher are fully qualified, and I generally give a full execution path in my configuration file, so consider using the option "--path=''".

Commands that need to be run as root you can run via "sudo". I often run process accounting which tracks all commands run. Tripwire may be useful to track changed configuration files.

TROUBLESHOOTING¶

To debug a configuration file the following options are useful:

   ps-watcher --log --nodaemon --sleep -1 --debug 2 *config-file*

For even more information and control try running the above under the perl debugger, e.g.

   perl -d ps-watcher --log --nodaemon --sleep -1 --debug 2 *config-file*

BUGS¶

Well, some of these are not so much a bug in ps-watcher so much as a challenge to getting ps-watcher to do what you want it to do.

One common problem people run in into is understanding exactly what the process variables mean. The manual page ps(1) should be of help, but I've found some of the descriptions either a bit vague or just plain lacking.

Sometimes one will see this error message when debug tracing is turned on:

  ** debug ** Something wrong getting ps variables

This just means that the process died between the time ps-watcher first saw the existence of the process and the time that it queried variables.

SEE ALSO¶

See also ps(1) and syslogd(8).

Another cool program doing ps-like things is "xps". Well okay, it's another program I distributed. It shows the process tree dynamically updated using X Motif and tries to display the output "attractively" but fast. You can the find the homepage at <http://motif-pstree.sourceforge.net> and it download via <http://prdownloads.sourceforge.net/motif-pstree?sort_by=date&sort=desc>

AUTHOR¶

Rocky Bernstein (rocky@gnu.org)

COPYRIGHT¶

  Copyright (C) 2000, 2002, 2003, 2004, 2005, 2006, 2008
  Rocky Bernstein, email: rocky@gnu.org.
  This program is free software; you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
  the Free Software Foundation; either version 2 of the License, or
  (at your option) any later version.
  This program is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  GNU General Public License for more details.
  You should have received a copy of the GNU General Public License
  along with this program; if not, write to the Free Software
  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.