Re: Locking a process or thread onto a specific CPU

Zygo Blaxell (uixjjji1@umail.furryterror.org)
19 Feb 1999 03:40:53 -0500


In article <36CCDD25.FA25DEA7@by.net>, Mike Goldman <whig@by.net> wrote:
>>>> Once in a while, a
>>>> student would write a program that essentially forked in a loop
>where
>>>> the parent process exited. This kind of process is _hard_ to kill
>>>> since neither is it visible using 'ps', nor is the PID constant. In
>>>> IRIX, it is easy to solve this problem by disabling 3 CPUs [snip].
>>>> In Linux, on a 4-way SMP system, you're stuck.
>
>>> Getting a little off topic, but you do not need to disable CPUs to
>fix
>>> that particular problem. Just get the process group id or session id
>
>>> (PGID or SID columns from ps xaj) and kill -9 -pgid or kill -9 -sid.
>
>> Consider the case where the process does a setsid() after fork(). The
>
>> problem doesn't go away.
>
>#!/bin/sh
>#
># slay 1.2 - kill all processes belonging to the specified user(s).
># by Chris Ausbrooks <fish@bucket.ualr.edu>
># based on kall (a script of unknown origin)
># Please mail me any suggestions or corrections.
># Donations welcome.
># Changes by Pawel Wiecek <coven@debian.org>

A long script, but it won't do the job either.

Assuming the processes are all running under one userid, just do this:

# su userid -c 'kill -9 -1'

Assuming SysV-ish signal semantics, you'll kill every process that userID
owns atomically (hmmm...well, maybe not atomically with multiple CPU's, but
you can probably kill 'em faster than the other CPU's can fork 'em, so
run kill(2) in a tight loop in a realtime process and you're all set. ;-).

-- 
Zygo Blaxell, Linux Engineer, Corel Corporation, zygob@corel.ca (work),
zblaxell@furryterror.org (play).  It's my opinion, I tell you! Mine! All MINE!
Size of 'diff -Nurw [...] winehq corel' as of Fri Feb 19 03:14:00 EST 1999
Lines/files:  In 5201 / 28, Out 30657 / 391, Both 35527 / 395

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/