A ksh problem about pgrep

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

Re: A ksh problem about pgrep

wrote in message
news:e187cc84-25aa-42ea-b3c3-c4f279814b99@a39g2000pre.google groups.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

Re: A ksh problem about pgrep

On 12/4/2007 2:13 AM, Vakayil Thobias wrote:
> wrote in message
> news:e187cc84-25aa-42ea-b3c3-c4f279814b99@a39g2000pre.google groups.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

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.

Re: A ksh problem about pgrep

Ed Morton wrote:
>
> On 12/4/2007 2:13 AM, Vakayil Thobias wrote:
>> wrote in message
>> news:e187cc84-25aa-42ea-b3c3-c4f279814b99@a39g2000pre.google groups.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

The OP did a precise match with pgrep -x.
This is at miminum grep -w "$CMD" | grep -vw "grep"

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

Correct but still inexact is

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

Due to the inexact match, the filtering program might be listed by ps,
but this is now awk!

Better one does a precise match:

ps -ef | awk '$NF==cmd {print $2}' cmd="$CMD"

No need to filter out awk.
(And instead of -v I used the old awk syntax.)

--
Michael Tosch @ hp : com

Re: A ksh problem about pgrep

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

Re: A ksh problem about pgrep

On 12ÔÂ5ÈÕ, ÉÏÎç4ʱ56·Ö, Michael Tosch 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...

Re: A ksh problem about pgrep

slin@alcatel-lucent.com wrote:
> On 12ÔÂ5ÈÕ, ÉÏÎç4ʱ56·Ö, Michael Tosch
> 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

Re: A ksh problem about pgrep

On 12ÔÂ5ÈÕ, ÏÂÎç7ʱ01·Ö, Michael Tosch d.SPAM.ericsson.PLS.se>
wrote:
> s...@alcatel-lucent.com wrote:
> > On 12ÔÂ5ÈÕ, ÉÏÎç4ʱ56·Ö, Michael Tosch O.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 reallytwoprocesses at the moment when running the
> >pgreporgrep.
> > 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 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

Re: A ksh problem about pgrep

On Dec 5, 7:12 am, s...@alcatel-lucent.com wrote:
> On 12ÔÂ5ÈÕ, ÏÂÎç7ʱ01·Ö, Michael Tosch eed.SPAM.ericsson.PLS.se>
> wrote:
>
>
>
>
>
> > s...@alcatel-lucent.com wrote:
> > > On 12ÔÂ5ÈÕ, ÉÏÎç4ʱ56·Ö, Michael Tosch @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 reallytwoprocesses at the moment when running the
> > >pgreporgrep.
> > > 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 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- 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.unix.shell/browse_thread /thread/45fa2547=
b6c8e1c8/b35c11fa95448b15?hl=3Den&lnk=3Dgst&q=3Dtomsellner#b 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

Re: A ksh problem about pgrep

Tom wrote:
> On Dec 5, 7:12 am, s...@alcatel-lucent.com wrote:
>> On 12ÔÂ5ÈÕ, ÏÂÎç7ʱ01·Ö, Michael Tosch
>> wrote:
>>
>>
>>
>>
>>
>>> s...@alcatel-lucent.com wrote:
>>>> On 12ÔÂ5ÈÕ, ÉÏÎç4ʱ56·Ö, Michael Tosch
>>>> wrote:
>>>> Thanks for your help.
>>>> I have tried your cases, but it still doesn't work.
>>>> It seems there are reallytwoprocesses at the moment when running the
>>>> pgreporgrep.
>>>> 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 canfork() on certain occasions,
>>> so appears astwoprocesses.
>>> In case the pipe leads to afor/usr/bin/pgrep-x "$CMD"k(),
>>> the following would help:
>>> pids=`/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- 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.unix.shell/browse_thread /thread/45fa2547b6c8e1c8/b35c11fa95448b15?hl=en&lnk=gst&q=to msellner#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

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