check and terminate processes by SW

Hello,

how can I figure out, what processes (PIDs) are running at the moment
and what are their name out of my own program? Need to check what
processes are running and to terminate some of them when they’re running
out of my process (similar to pidin and slay on command line).

Do I have to parse the contents of /proc ? If, then how to know what
process stands behind the pid?

Wolfram

Wolfram Manthey wrote:

Hello,

how can I figure out, what processes (PIDs) are running at the moment
and what are their name out of my own program? Need to check what
processes are running and to terminate some of them when they’re running
out of my process (similar to pidin and slay on command line).

Do I have to parse the contents of /proc ? If, then how to know what
process stands behind the pid?

Well there are three ways (possibly more) to do this:

  1. The best way ™. Design a message based architecture for all of your
    processes that includes a terminate message. Design your “master” process
    as a resource manager that registers a prefix that all of your child
    processes open(). Since all of your child processes will perform an
    open() to your “master” process, you automatically have a list of all the
    pids of your children (which you can do with as you like). When you child
    processes terminate for any reason your “master” process will receive a
    close on the prefix and can remove the process from it’s internal list or
    restart it or whatever. When you wish to terminate a process, rather than
    hit it with an asynchronous signal, send a synchronous terminate message
    (note that other than the open, the children never send to the master
    process). If your child process does not respond to the terminate message
    THEN FIX IT (you wouldn’t believe how many times I have heard this as an
    excuse for using signal based termination). This method is fully
    synchronous and robust. This method does not require that your master
    process actually spawn() the child processes (although it can).

  2. The common unixy, but sucky way. Start all your child processes from
    the master process and collect the pids into a list. Register a SIGCHLD
    handler in your master process and either delete terminated processes from
    your list or restart them. This method is asynchronous and (if not done
    very carefully) non robust. This method requires that the “master”
    process also spawn() the children.

  3. The uncommon wacky way. Use the /proc interface to poll the currently
    running process list (have some config file to let you know which process
    names are “yours”), when you see a process disappear from the list imply
    that it has died and remove it from your list, or restart. This method is
    synchronous, and low performance, and should be relatively easy to make
    robust. This method does not require that the “master” process spawn()
    the children, although it can.

  4. Oddball combinations of 1,2,3 ?

I have implemented and maintained design number 1, and had to maintain 2,
and number 1 is much more robust, and easy to maintain. I have never
tried number 3, since it simply goes against my (exception based) grain.

To answer your question on the proc interface, goto cvs.qnx.com, and
download the source for pidin. It will answer all your questions.

Rennie

“Rennie Allen” <rallen@csical.com> wrote in message
news:bfjqsp$ob3$1@tiger.openqnx.com

Wolfram Manthey wrote:

Hello,

how can I figure out, what processes (PIDs) are running at the moment
and what are their name out of my own program? Need to check what
processes are running and to terminate some of them when they’re running
out of my process (similar to pidin and slay on command line).

Do I have to parse the contents of /proc ? If, then how to know what
process stands behind the pid?

Well there are three ways (possibly more) to do this:

  1. The best way ™. Design a message based architecture for all of your
    processes that includes a terminate message. Design your “master” process
    as a resource manager that registers a prefix that all of your child
    processes open(). Since all of your child processes will perform an
    open() to your “master” process, you automatically have a list of all the
    pids of your children (which you can do with as you like). When you child
    processes terminate for any reason your “master” process will receive a
    close on the prefix and can remove the process from it’s internal list or
    restart it or whatever. When you wish to terminate a process, rather than
    hit it with an asynchronous signal, send a synchronous terminate message
    (note that other than the open, the children never send to the master
    process). If your child process does not respond to the terminate message
    THEN FIX IT (you wouldn’t believe how many times I have heard this as an
    excuse for using signal based termination). This method is fully
    synchronous and robust. This method does not require that your master
    process actually spawn() the child processes (although it can).

  2. The common unixy, but sucky way. Start all your child processes from
    the master process and collect the pids into a list. Register a SIGCHLD
    handler in your master process and either delete terminated processes from
    your list or restart them. This method is asynchronous and (if not done
    very carefully) non robust. This method requires that the “master”
    process also spawn() the children.

  3. The uncommon wacky way. Use the /proc interface to poll the currently
    running process list (have some config file to let you know which process
    names are “yours”), when you see a process disappear from the list imply
    that it has died and remove it from your list, or restart. This method is
    synchronous, and low performance, and should be relatively easy to make
    robust. This method does not require that the “master” process spawn()
    the children, although it can.

  4. Oddball combinations of 1,2,3 ?

I have implemented and maintained design number 1, and had to maintain 2,
and number 1 is much more robust, and easy to maintain. I have never
tried number 3, since it simply goes against my (exception based) grain.

To answer your question on the proc interface, goto cvs.qnx.com, and
download the source for pidin. It will answer all your questions.

Rennie


Is there a standard way for the master process to get the names of the other

processes with the first method you outlined?.

JV wrote:

Is there a standard way for the master process to get the names of the other
processes with the first method you outlined?.

You must mean in the case where the master process does not spawn the children,
since obviously, if it is spawning the children it must know their names (since
it gives them their “names” - i.e. argv[0]).

In the case where the master does not spawn the processes the /proc interface
can be used to obtain the name of the executable associated with the pid. I
guess the question is, since the pid of the process is already resolved, of what
additional value is the name of the executable associated with the process ?

Rennie

Yes, I was referring to the case where the master does not spawn the
children.
I was considering the case where the master process must react to a process
terminating, and must react differently depending on which process
terminated. I think the name of the executable is not an ideal way to ID
the process. Perhaps another standard message, in addition to the terminate
message, would facilitate this.

Thanks,

Jon

“Rennie Allen” <rgallen@attbi.com> wrote in message
news:bfu7b3$aa4$1@inn.qnx.com

JV wrote:


Is there a standard way for the master process to get the names of the
other
processes with the first method you outlined?.

You must mean in the case where the master process does not spawn the
children,
since obviously, if it is spawning the children it must know their names
(since
it gives them their “names” - i.e. argv[0]).

In the case where the master does not spawn the processes the /proc
interface
can be used to obtain the name of the executable associated with the pid.
I
guess the question is, since the pid of the process is already resolved,
of what
additional value is the name of the executable associated with the process
?

Rennie