On Fri, 14 Jan 2000, Pavel Machek wrote:
> Sorry, alan. No. Unix is broken with this part.
When you run as root, you run risks and have to be careful. The very _nice_
thing about Unix is that it wraps pids and does _not_ pick random pids. You shouldn't
get around to the same pid for at least a reasonable amount of time, unless someone
is spawning processes _very_ fast.
> But that's wrong. Pavel may have seen you are going to kill his emacs
> and may have wrapped pids, killed his emacs himself, and you are now
> killing _your_ netscape you've just ran.
Erm, too bad that's exactly what _doesn't_ happen under Unix. Your netscape
you just started will get a new pid, after the latest one taken. No matter if that
process died or not.
> Alan, I'm searching for ways to safely kill the process (something
> like "I want to kill process #209, started 13:25. Given it is at least
> 13:26, it is unique :-), but I see none.
This is silly. The way to do it is _very_ simple. Every process has it's
own unique process id. This process id is _never_ reused, even when the process
dies. This is the best solution I see for what you are doing, however, it is not
very practical really. It becomes more so with a 32bit PID, but even then, you
have to figure out what to do when you run out. reboot? There is one interesting
thing, if you can say that on average there will not be a new process more often
than one per second, then perhaps you could do it for around 60 years. Of course,
I have no idea if things will happen that way or not..
Someone want to sit and count sometime, how many processes are started
in a given (longish) time period? One thing that would be kind of cute to handle
this would be a kernel log message saying every time the PID count rolled over.
Stephen
-
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/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:12 EST