Man Linux: Main Page and Category List

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).

   OPTIONS
       --help
           Print a usage message on standard error and exit with a return code
           of 100.

       --doc
           Extact the full documentation that you are reading now, print it
           and exit with a return code of 101.

       --version
           Print the version release on standard output and exit with a return
           code of 10.

       --debug number
           Give debugging output. The higher the number, the more the output.
           The default is 0 = none. 2 is the most debugging output.

       [--config] configuration file
           Specify configuration file. .

           See "CONFIGURATION FILE FORMAT" below for information on the format
           of the configuration file and "EXAMPLE CONFIGURATION" for a
           complete example of a configuration file.

       --log [log file]
           Send or don’t send error and debugging output to a log file. If
           option is given but no logfile is specified, then use STDERR. The
           default is no error log file.  See also --syslog below.

       --syslog | --nosyslog
           Send or don’t send error and debugging output to syslog. The
           default is to syslog error and debug output.

       --daemon | --nodaemon
           Run or don’t as a daemon.

       --path search-path
           Specify the executable search path used in running commands.

       --ps-prog program
           One can specify the command that gives ps information. By default,
           the command is /bin/ps.

       --run | --norun
           do/don’t run actions go through the motions as though we were going
           to. This may be useful in debugging.

       --sleep interval in seconds
           It is expected that one might want to run ps-watcher over and over
           again. In such instances one can specify the amount of time between
           iterations with this option.

           If a negative number is specified the program is run only once.

   CONFIGURATION FILE MODIFICATION AND SIGNAL HANDLING
       Periodically ps-watcher checks to see if the configuration file that it
       was run against has changed. If so, the program rereads the
       configuration file.

       More precisely, the checks are done after waking up from a slumber.  If
       the sleep interval is long (or if you are impatient), you can probably
       force the program to wake up using a HUP signal.

       At any time you can increase the level of debug output by sending a
       USR1 signal to the ps-watcher process. Similarly you can decrease the
       level of debug output by sending the process a USR2 signal.

       It is recommended that you terminate ps-watcher via an INT, TERM, or
       QUIT signal.

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"

   EXPANDED VARIABLES IN TRIGGER/ACTION CLAUSES
       Any variables defined in the program can be used in pattern or action
       parameters. For example, $program can be used to refer to the name of
       this program ps-watcher.

       The following variables can be used in either the pattern or action
       fields.

       $action
           A string containing the text of the action to run.

       $perl_action
           A string containing the text of the perl_action to run.

       $ps_pat
           The Perl regular expression specified in the beginning of the
           section.

       $command
           The command that matched $ps_pat.

           The Perl regular expression specified in the beginning of the
           section.  Normally processes will not have funny characters in
           them. Just in case, backticks in $command are escaped.

           Example:

             # List processes other than emacs (which is a known pig) that use lots
             # of virtual memory

             [.*]
             trigger = $command !~ /emacs$/ && $vsz > 10
             action  = echo \"Looks like you have a big \$command program: \$vsz KB\"

       $count
           The number of times the pattern matched. Presumably the number of
           processes of this class running.

       $trigger
           A string containing the text of the trigger.

       A list of variables specific to this program or fields commonly found
       in "ps" output is listed below followed by a description of the more
       common ones. See also "ps" for a more complete description of the
       meaning of the field.

        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

       Beware though, in some situations ps can return multiple lines for a
       single process and we will use just one of these in the trigger. In
       particular, Solaris’s "ps" will return a line for each LWP (light-
       weight process). So on Solaris, if a trigger uses variable lwp, it may
       or may not match depending on which single line of the multiple "ps"
       lines is used.

       $args
           The command along with its command arguments. It is possible that
           this is might get truncated at certain length (if ps does likewise
           as is the case on Solaris).

       $ppid
           The parent process id.

       $stime
           The start time of the process.

       $etime
           The end time of the process.

       $pmem
           The process memory.

       $pcpu
           The percent CPU utilization.

       $tty
           The controlling tty.

       $vsz
           Virtual memory size of the process

   OTHER THINGS IN TRIGGER CLAUSES
       To make testing against elapsed time easier, a function "elapse2sec()"
       has been written to parse and convert elapsed time strings in the
       format "dd-hh:mm:ss" and a number of seconds.

       Some constants for the number of seconds in a minute, hour, or day have
       also been defined. These are referred to as "MINS", "HOURS", and "DAYS"
       respectively and they have the expected definitions:

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

       Here is an example of the use of "elapsed2sec()":

         # 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

       Please note the quotes around ’$etime’.

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.