You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Michael Davey <Mi...@coderage.org> on 2004/06/05 23:19:07 UTC
core/gumpenv.py and check_pgrep
Hi,
PythonGump's check_pgrep test fails on Solaris when pgrep is present.
The problem is that pgrep returns error code 2 on Solaris but code 0 on
Linux:
bash$ pgrep -help
pgrep: illegal option -- h
Usage: pgrep [-flnovx] [-d delim] [-P ppidlist] [-g pgrplist] [-s sidlist]
[-u euidlist] [-U uidlist] [-G gidlist] [-J projidlist]
[-T taskidlist] [-t termlist] [pattern]
bash$ echo $?
2
Here is the relevent section of the Solaris 9 pgrep/pkill man page:
EXIT STATUS
The following exit values are returned:
0 One or more processes were matched.
1 No processes were matched.
2 Invalid command line options were specified.
3 A fatal error occurred.
One possible fix would be to issue "pgrep init" instead of "pgrep
-help". I *think* that all *nix has the init process. If agreeable,
I'll submit a patch.
--
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: core/gumpenv.py and check_pgrep
Posted by Michael Davey <Mi...@coderage.org>.
Adam R. B. Jack wrote:
>
>>what about the "type" command/built-in? Can we assume that either the
>>python execute command will always execute the command in bash or find
>>the "type" executable?
>>
>>
>
>Nice idea. Not sure it is portable enough (for Microsoft) to be quite worth
>the effort, but maybe. I suspect there is a way to search a path for an
>executable, and that is how we ought implement it. Mind you, I could easily
>live w/ a *nix flavour that works nicer than Microsoft, since most of our
>big serves are *Nix.
>
>
We could always fall back on the current way of doing things if the test
fails.
I'll look at a patch to do this.
>
>
>>>One things I dislike about
>>>pgrep is it doesn't kill grandchildren (a perfectly good attribute out
>>>outside of computing) -- so only kills the child shell, not even the main
>>>program below. That all said, it stops Gump from hanging.
>>>
>>>
>>>
>>>
>>;) If you ensure that the group id is set for all children, then
>>wouldn't a pgrep -g id do the trick? I don't know how you would achieve
>>that with python, but in C you would use setgid(id);
>>
>>
>
>I once looked into group ids, thinking they might be the answer, but
>didn't/don't know enough about them to come up with a plan. I suspect that
>some fork/exec, along with this, and with popenN could do it (again, for
>*Nix) but I've not had time to work it out.
>
>
group ids generally and setgid() (or maybe it is setpgrp()) specifically
are explained well in "Advanced Programming in the UNIX Environment
(APC)" by W.Richard Stevens, published by Addison Wesley. I no longer
have access to a copy.
>Maybe we could write some test modules to do this stuff (portably) and test
>them in unit tests, and then work them in.
>
>
Good plan. Might be worth downloading
http://www.kohala.com/start/apue.html the sample source and see if there
are any examples of this.
--
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: core/gumpenv.py and check_pgrep
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> >One thing I dislike about Python (for Gump) is we've not found a nicer
way
> >to timeout processes. One thing I dislike about Gump's implementation
(for
> >this part) is that it runs the program, not just detects it on the PATH -
> >but this is 'cos since we had code to do this
> >
> what about the "type" command/built-in? Can we assume that either the
> python execute command will always execute the command in bash or find
> the "type" executable?
Nice idea. Not sure it is portable enough (for Microsoft) to be quite worth
the effort, but maybe. I suspect there is a way to search a path for an
executable, and that is how we ought implement it. Mind you, I could easily
live w/ a *nix flavour that works nicer than Microsoft, since most of our
big serves are *Nix.
> >One things I dislike about
> >pgrep is it doesn't kill grandchildren (a perfectly good attribute out
> >outside of computing) -- so only kills the child shell, not even the main
> >program below. That all said, it stops Gump from hanging.
> >
> >
> ;) If you ensure that the group id is set for all children, then
> wouldn't a pgrep -g id do the trick? I don't know how you would achieve
> that with python, but in C you would use setgid(id);
I once looked into group ids, thinking they might be the answer, but
didn't/don't know enough about them to come up with a plan. I suspect that
some fork/exec, along with this, and with popenN could do it (again, for
*Nix) but I've not had time to work it out.
Maybe we could write some test modules to do this stuff (portably) and test
them in unit tests, and then work them in.
Thanks for both ideas.
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: core/gumpenv.py and check_pgrep
Posted by Michael Davey <Mi...@coderage.org>.
Adam R. B. Jack wrote:
>One thing I dislike about Python (for Gump) is we've not found a nicer way
>to timeout processes. One thing I dislike about Gump's implementation (for
>this part) is that it runs the program, not just detects it on the PATH -
>but this is 'cos since we had code to do this
>
what about the "type" command/built-in? Can we assume that either the
python execute command will always execute the command in bash or find
the "type" executable?
>One things I dislike about
>pgrep is it doesn't kill grandchildren (a perfectly good attribute out
>outside of computing) -- so only kills the child shell, not even the main
>program below. That all said, it stops Gump from hanging.
>
>
;) If you ensure that the group id is set for all children, then
wouldn't a pgrep -g id do the trick? I don't know how you would achieve
that with python, but in C you would use setgid(id);
>If you work on a patch ... I think some folks could use pgrep on Microsoft
>platforms, so please be cautious of those. Perhaps (in that case) continue
>with -help.
>
[snip]
--
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: core/gumpenv.py and check_pgrep
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
One thing I dislike about Python (for Gump) is we've not found a nicer way
to timeout processes. One thing I dislike about Gump's implementation (for
this part) is that it runs the program, not just detects it on the PATH -
but this is 'cos since we had code to do this. One things I dislike about
pgrep is it doesn't kill grandchildren (a perfectly good attribute out
outside of computing) -- so only kills the child shell, not even the main
program below. That all said, it stops Gump from hanging.
If you work on a patch ... I think some folks could use pgrep on Microsoft
platforms, so please be cautious of those. Perhaps (in that case) continue
with -help. [There are a few places where OS checks are made already, you
could copy those.]
BTW: I could be talked into deprecating pgrep, in favour of 'timeout' (the
program Sam found, if it could be coded for multi-threads/multi-CPU).
regards,
Adam
----- Original Message -----
From: "Michael Davey" <Mi...@coderage.org>
To: "Gump code and data" <ge...@gump.apache.org>
Sent: Saturday, June 05, 2004 3:19 PM
Subject: core/gumpenv.py and check_pgrep
> Hi,
>
> PythonGump's check_pgrep test fails on Solaris when pgrep is present.
> The problem is that pgrep returns error code 2 on Solaris but code 0 on
> Linux:
>
> bash$ pgrep -help
> pgrep: illegal option -- h
> Usage: pgrep [-flnovx] [-d delim] [-P ppidlist] [-g pgrplist] [-s sidlist]
> [-u euidlist] [-U uidlist] [-G gidlist] [-J projidlist]
> [-T taskidlist] [-t termlist] [pattern]
> bash$ echo $?
> 2
>
>
> Here is the relevent section of the Solaris 9 pgrep/pkill man page:
>
> EXIT STATUS
> The following exit values are returned:
>
> 0 One or more processes were matched.
>
> 1 No processes were matched.
>
> 2 Invalid command line options were specified.
>
> 3 A fatal error occurred.
>
>
> One possible fix would be to issue "pgrep init" instead of "pgrep
> -help". I *think* that all *nix has the init process. If agreeable,
> I'll submit a patch.
>
> --
> Michael
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org