Unix Shell - A ksh problem about pgrep

Author

A ksh problem about pgrep

slin@alcatel-lucent.com

2007-12-04, 1:38 am

Hi, everyone,

I met a strange ksh problem, can anyone give me some hints? The
"apply.sh" script dot in the common script "comm.sh", when I run the
apply.sh, it sometime reports the process is already running, but
actually there is only one apply.sh running at the time.
Does my code have any problem?

I copy my code here:

-- comm.sh --
#! /usr/bin/ksh

# the command run by the user
CMD="`basename $0`"

function check_proc
{
# check if the script is already running
if /usr/bin/pgrep -x "$CMD" | /usr/bin/grep -v $$ > /dev/null
2>&1
then
echo "$CMD: ERROR - process is already running. Exit...\n"
exit 1
fi
}
....

--- apply.sh ----
#!/usr/bin/ksh

CURDIR=$(/bin/dirname $0)
.. $CURDIR/comm.sh

# trap the signal and call Exit to exit the script
trap 'Exit ' HUP INT QUIT TERM

# check if the process is already running
check_proc
....

Thanks for your help!
Jason

Vakayil Thobias

2007-12-04, 7:34 am

<slin@alcatel-lucent.com> wrote in message
news:e187cc84-25aa-42ea-b3c3-c4f279814b99@a39g2000pre.googlegroups.com...
> Hi, everyone,
>
> I met a strange ksh problem, can anyone give me some hints? The
> "apply.sh" script dot in the common script "comm.sh", when I run the
> apply.sh, it sometime reports the process is already running, but
> actually there is only one apply.sh running at the time.
> Does my code have any problem?
>
> I copy my code here:
>
> -- comm.sh --
> #! /usr/bin/ksh
>
> # the command run by the user
> CMD="`basename $0`"
>
> function check_proc
> {
> # check if the script is already running
> if /usr/bin/pgrep -x "$CMD" | /usr/bin/grep -v $$ > /dev/null
> 2>&1
> then
> echo "$CMD: ERROR - process is already running. Exit...\n"
> exit 1
> fi
> }
> ...
>
> --- apply.sh ----
> #!/usr/bin/ksh
>
> CURDIR=$(/bin/dirname $0)
> . $CURDIR/comm.sh
>
> # trap the signal and call Exit to exit the script
> trap 'Exit ' HUP INT QUIT TERM
>
> # check if the process is already running
> check_proc
> ...
>
> Thanks for your help!
> Jason

processid=`ps -ef | grep "$CMD" | grep -v "grep" | awk [{print $2}'
check if processid greater than 0

Ed Morton

2007-12-04, 1:25 pm

On 12/4/2007 2:13 AM, Vakayil Thobias wrote:
> <slin@alcatel-lucent.com> wrote in message
> news:e187cc84-25aa-42ea-b3c3-c4f279814b99@a39g2000pre.googlegroups.com...
>
>
>
> processid=`ps -ef | grep "$CMD" | grep -v "grep" | awk [{print $2}'
> check if processid greater than 0

Assuming that, once the syntax errors are corrected, that script does what you
want, there's no need for the greps and pipelines:

ps -ef | awk -v cmd="$CMD" '$0~cmd && !/grep/ {print $2}'

Ed.

Michael Tosch

2007-12-04, 7:25 pm

slin@alcatel-lucent.com wrote:
> Hi, everyone,
>
> I met a strange ksh problem, can anyone give me some hints? The
> "apply.sh" script dot in the common script "comm.sh", when I run the
> apply.sh, it sometime reports the process is already running, but
> actually there is only one apply.sh running at the time.
> Does my code have any problem?
>
> I copy my code here:
>
> -- comm.sh --
> #! /usr/bin/ksh
>
> # the command run by the user
> CMD="`basename $0`"
>
> function check_proc
> {
> # check if the script is already running
> if /usr/bin/pgrep -x "$CMD" | /usr/bin/grep -v $$ > /dev/null
> 2>&1
> then
> echo "$CMD: ERROR - process is already running. Exit...\n"
> exit 1
> fi
> }
> ...
>
> --- apply.sh ----
> #!/usr/bin/ksh
>
> CURDIR=$(/bin/dirname $0)
> . $CURDIR/comm.sh
>
> # trap the signal and call Exit to exit the script
> trap 'Exit ' HUP INT QUIT TERM
>
> # check if the process is already running
> check_proc
> ...
>
> Thanks for your help!
> Jason

Do an exact match:

/bin/grep -vw $$

or

/bin/fgrep -vx $$

--
Michael Tosch @ hp : com

slin@alcatel-lucent.com

2007-12-05, 7:32 am

On 12=D4=C25=C8=D5, =C9=CF=CE=E74=CA=B156=B7=D6, Michael Tosch <eed...@NO.ee=
d.SPAM.ericsson.PLS.se>
wrote:

Thanks for your help.

I have tried your cases, but it still doesn't work.
It seems there are really two processes at the moment when running the
pgrep or grep.
I have no idea now...

Michael Tosch

2007-12-05, 7:32 am

slin@alcatel-lucent.com wrote:
> On 12ÔÂ5ÈÕ, ÉÏÎç4Ê±56·Ö, Michael Tosch <eed...@NO.eed.SPAM.ericsson.PLS.se>
> wrote:
>
> Thanks for your help.
>
> I have tried your cases, but it still doesn't work.
> It seems there are really two processes at the moment when running the
> pgrep or grep.
> I have no idea now...

And you tried with

if /usr/bin/pgrep -x "$CMD" | /bin/fgrep -vx $$ > /dev/null
then
...
fi
?

In theory a shell can fork() on certain occasions,
so appears as two processes.

In case the pipe leads to a fork(),
the following would help:

pids=`/usr/bin/pgrep -x "$CMD"`
case $pids in
$$)
;;
*)
...
;;
esac

--
Michael Tosch @ hp : com

slin@alcatel-lucent.com

2007-12-05, 7:32 am

On 12=D4=C25=C8=D5, =CF=C2=CE=E77=CA=B101=B7=D6, Michael Tosch <eed...@NO.ee=
d.SPAM.ericsson.PLS.se>
wrote:
> s...@alcatel-lucent.com wrote:
O.eed.SPAM.ericsson.PLS.se>[vbcol=seagreen]
>
>
>
> And you tried with
>
> if /usr/bin/pgrep-x "$CMD" | /bin/fgrep -vx $$ > /dev/null
> then
> ...
> fi
> ?
>
> In theory a shell canfork() on certain occasions,
> so appears astwoprocesses.
>
> In case the pipe leads to afork(),
> the following would help:
>
> pids=3D`/usr/bin/pgrep-x "$CMD"`
> case $pids in
> $$)
> ;;
> *)
> ...
> ;;
> esac
>
> --
> Michael Tosch @ hp : com

Yes, I have tried the /bin/fgrep -vx $$, but it didn't work.
and I just verify again with the new code, it does work now. I think
we got the root cause.

Really appreciated all your helps!

Jason

Tom

2007-12-06, 1:29 pm

On Dec 5, 7:12 am, s...@alcatel-lucent.com wrote:
> On 12=D4=C25=C8=D5, =CF=C2=CE=E77=CA=B101=B7=D6, Michael Tosch <eed...@NO.=
eed.SPAM.ericsson.PLS.se>
> wrote:
>
>
>
>
>
@NO.eed.SPAM.ericsson.PLS.se>[vbcol=seagreen]
>
>
>
>
>
>
>
>
>
> Yes, I have tried the /bin/fgrep -vx $$, but it didn't work.
> and I just verify again with the new code, it does work now. I think
> we got the root cause.
>
> Really appreciated all your helps!
>
> Jason- Hide quoted text -
>
> - Show quoted text -

What was your solution? I had a similar issue where the function in
the process table, actually is reported in the process table as the
calling script.

See:
http://groups.google.com/group/comp...hread/45fa2547=
b6c8e1c8/b35c11fa95448b15?hl=3Den&lnk=3Dgst&q=3Dtomsellner#b35c11fa95448b15

Basically just had to look at who the parent of the process was, and
if in your case, apply.sh has a parent of apply.sh, then you would
know it's your function, not the parent, apply.sh

Not sure if that's the best answer or not ...
Thanks, Tom

Michael Tosch

2007-12-06, 1:29 pm

Tom wrote:
> On Dec 5, 7:12 am, s...@alcatel-lucent.com wrote:
>
> What was your solution? I had a similar issue where the function in
> the process table, actually is reported in the process table as the
> calling script.
>
> See:
> http://groups.google.com/group/comp...35c11fa95448b15
>
> Basically just had to look at who the parent of the process was, and
> if in your case, apply.sh has a parent of apply.sh, then you would
> know it's your function, not the parent, apply.sh
>
> Not sure if that's the best answer or not ...
> Thanks, Tom

The fix was to avoid a potential race condition:
if the shell does a fork() first, then executes the "pgrep" before the
exec() has changed the name in the process table.

A similar fix would have been

pids=`/usr/bin/pgrep-x "$CMD"`
echo "$pids" | fgrep -vx $$

I think in your case the func& does a fork() and this process runs
as func_a but with the name of the shell. (No way to set $0.)
Unlike Barry Margolin, I think the & forces the shell to at least
start a new asynchronous thread if not a new process (fork()).

You are right, testing against the parent $$ is a more general way
to solve this.

--
Michael Tosch @ hp : com