Prev: libc.info
Next: si_pid in siginfo_t never set in FreeBSD 6
From: DanielJohnson on 13 Jun 2008 20:15

> killall -s USR1 "user supplied parameter"
>

That surely is the most intuitive solution. But since I have to worry
about sending this command in the program (where I have to manipulate
with log levels of the pids), its not the best for such scenarios.

I went through the code of killall.c but couldn't understand
everything clearly as to what and how are they doing the process
count. It is a little intricate.Can somebody throw some insight into
the killall logic or any other means of tracking pids of all the
process whose name matches with the "proc name".


From: phil-news-nospam on 16 Jun 2008 14:30
On Fri, 13 Jun 2008 17:15:14 -0700 (PDT) DanielJohnson <diffuser78(a)gmail.com> wrote:

| That surely is the most intuitive solution. But since I have to worry
| about sending this command in the program (where I have to manipulate
| with log levels of the pids), its not the best for such scenarios.
|
| I went through the code of killall.c but couldn't understand
| everything clearly as to what and how are they doing the process
| count. It is a little intricate.Can somebody throw some insight into
| the killall logic or any other means of tracking pids of all the
| process whose name matches with the "proc name".

If you want to do this inside your own program on a Linux system, you can code
it to read all the process IDs via opendir("/proc") and readdir() all the
entries, selecting those that are pure decimals numbers. Then for each of
those selected, construct the path "/proc/XXXXX/exe" substituting XXXXX with
the process ID number in decimal. Call readlink() giving that path as the
first argument, and a string to store the link contents in the second (pointer
to buffer space) and third (length of buffer space) arguments. If readlink
gives no error, check the stored path to see if it matches the program path
you want to kill all the processes of. This is roughly what killall does on
Linux.

If you want to kill processes on some other basis, like what their parent
process ID (in "status"), current working directory (in "cwd"), environment
variable setting (in "environ"), open descriptor (in "fd/NNN"), etc, is,
you can read the other /proc/XXXXX entries to compare data (often with some
parsing needed).

You may want to, in certain cases, repeat the loop across process IDs to see
if new ones showed up. This would be needed if you are trying to kill off
a runaway forking program (and it isn't easy this way ... killing by process
group might be easier if the processes are not changing group and you don't
mind killing every process in the group).

For other UNIX systems, you will need to find out what needs to be done on
those. The source code for their equivalent of Linux "killall" should be
consulted. Or you could call system() or popen() to initiate the "killall"
program (on Linux) or equivalent (on other than Linux).

It would be nice if there was a POSIX standard for this kind of thing. But
there isn't, so we have to do the best we can (which involves non-portable
methods that generally work fine).

--
|WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
| by the abuse department, bellsouth.net is blocked. If you post to |
| Usenet from these places, find another Usenet provider ASAP. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |
From: Stephane CHAZELAS on 16 Jun 2008 14:48
2008-06-16, 18:30(+00), phil-news-nospam(a)ipal.net:
[...]
> It would be nice if there was a POSIX standard for this kind of thing. But
> there isn't, so we have to do the best we can (which involves non-portable
> methods that generally work fine).
[...]

On a number of systems, there is a "-C" option to ps, so that

ps -o pid= -C foo

gives a list of pids where the command name (either filename or
basename(argc[0]) I don't know) is foo.

On HPUX, it's enabled when the UNIX95 env variable is set which
makes me wonder if it comes from some sort of standard.

Most systems have a command to do the equivalent: ps -C, pidof,
killall -s, pgrep, pfind...

With POSIX, you can parse the output of ps -eo pid= -o comm=

--
St�phane
From: William Ahern on 16 Jun 2008 17:33
phil-news-nospam(a)ipal.net wrote:
<snip>
> It would be nice if there was a POSIX standard for this kind of thing. But
> there isn't, so we have to do the best we can (which involves non-portable
> methods that generally work fine).

Killing process groups is the standard way. There'll never be a standard for
haphazardly manipulating arbitrary sets of processes externally, because
there is likely no suitable solution to such an ill-defined problem.

If the OP is trying to send SIGUSR1 to OpenSSH processes, presumably he's
altered the source code. In which case, choosing SIGUSR1 as the mechanism to
control all sub-processes was manifestly a poor choice--technically
speaking--unless there's some other sufficient, unspoken constraint. OpenSSH
has a descriptor event loop; using pipes for communication would probably
have been the better choice, even given that OpenSSH source is complete
spaghetti.

It's understandable that the beguiling SIGUSR1 was selected. Live and learn,
I guess. Sometimes the best solution to hard problems is to redefine the
problem.

 | 
Pages: 1
Prev: libc.info
Next: si_pid in siginfo_t never set in FreeBSD 6