Quote:> "current time - elapsed time from ps" disqualifies as
> current time and elapsed time from ps are taken at different
> times, it may be off by a few seconds.
"A few seconds" seems unlikely. What kind of precision do you need?
$first = time;
$elapsed = `ps -o etime -p $PID`;
$last = time;
If first == $last, then do your calculation and you'll be accurate to
the second. If not, try again. I ran that several times in a perl
script and never had a second boundary appear.
Quote:> (2)
> How can I kill a process without worrying killing a wrong process?
> For example,
> some_process & pid=$!
> kill $pid
> The $pid may be a recycled new process.
Outside of the job control suggestion, I'm unaware of any way to refer
to a process by other than the PID, and there's no way I know of to
guarantee there's no race condition there.
However, you could probably put some bounds on things on a system where
PIDs are generated sequentially. Fork a process to generate a PID and
see if it is within some range of your target PID. If the distance is
large, you can be reasonably certain the PID will not be reused in the
time it takes to send the signal.
If the distance is small, then you have to make a decision about whether
you could delay the signal until the current PID passes the running
process PID. If there's some other mechanism that would be useful here,
that would be cool, but I don't know what it is.
Best would be if the signal didn't actually kill the process but made it
do a lookup for some other data, verified that it's the one in question,
and then killed itself. Then the race condition doesn't occur.
--
Unix System Administrator Taos - The SysAdmin Company
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
by