Re: process control

• Previous message: Andrew DeFaria: "Bash traps - while emitting ERR trap"
• In reply to: Leiji Liu: "process control"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Thu, 31 Jul 2003 00:18:39 +0200

In article <vbXVa.1469$wV5.22@newssvr22.news.prodigy.com>, Leiji Liu wrote:
>
> #!/bin/ksh
> check=`ps -ef |grep "/bin/ksh /home/mycode/allrun.sh" | wc -l`
> if [ $check = 2 ] ; then
> process my programs
> fi
>
> Here is the question. Why should the $check be 2? Or should it be better
> $check < 2? When I manually start "allrun.sh" (not from cron table) from
> command line, the $check is 0. Can anybody give me some explanation?

Both Solaris and HP-UX (and possibly others) seem extremely variable
in the number of processes they report in this situation. I would
*expect* that the correct number of processes containing the
grep pattern is (a) one for the script itself (b) one for the pattern occurring
on the grep commandline which ps will see and grep will grep out
(c) possibly one more for the backquotes creating a subshell (but I
think this is implementation specific), but then probably remove (b) because
the ps output is probably not wide enough to show the whole grep
pattern so grep won't find it in the ps listing after all. So in
total 2.

But as I said, in my experience this number varies (ps timing? race
conditions?) and it is not a reliable method to test if a process is
running. Better to put the PID of the running process in a file with
well known location:

        #!/bin/ksh
        PROGNAME=`basename $0` # yes, ksh can do this nicer ways
        echo $$ > /var/locks/$PROGNAME.pid

but actually do this only after it has tested to see if the file exists
already and corresponds to a running PID (not checked!):

        #!/bin/ksh
        PROGNAME=`basename $0` # yes, ksh can do this nicer ways
                                        # throw away errors caused by non-existent file
        PREVIOUS_PID=`cat /var/locks/$PROGNAME.pid 2>/dev/null`

                                        # if have old pid and is running abort
        [ "X$PREVIOUS_PID" != X -a [ "X`ps -ef | grep \" $PREVIOUS_PID \"`" != X ] && {
                echo "$PROGNAME: ERROR: locked!" >&2
                exit 1
        }
                                        # this is nicer way to do the same but less
                                        # portable (-f or -d? check!)
        [ "X$PREVIOUS_PID" != X -a -f /proc/$PREVIOUS_PID ] && {
                echo "$PROGNAME: ERROR: locked!" >&2
                exit 1
        }
        }
        echo $$ > /var/locks/$PROGNAME.pid

There is clearly a race condition possible here (second invocation
starts up between us seeing no lock file and us creating one). Search
comp.unix.shell archives for extensive discussion on how to
"test for old locks and insert new ones" in an indivisible step.

--
Alexis
http://dione.no-ip.org/~alexis/

• Previous message: Andrew DeFaria: "Bash traps - while emitting ERR trap"
• In reply to: Leiji Liu: "process control"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]