Re: CVS commit: src/usr.bin/pkill

[Warner Losh <imp%bsdimp.com@localhost>]

On Nov 21, 2012, at 1:25 PM, Christos Zoulas wrote:

> In article <20121121200309.GN508%snowdrop.l8s.co.uk@localhost>,
> David Laight  <david%l8s.co.uk@localhost> wrote:
>> On Wed, Nov 21, 2012 at 12:43:20PM -0500, Christos Zoulas wrote:
>>> On Nov 22,  4:39am, mrg%eterna.com.au@localhost (matthew green) wrote:
>>> -- Subject: re: CVS commit: src/usr.bin/pkill
>>> 
>>> | this seems like a fairly big semantic change to me.
>>> | 
>>> | could you change it to take a new option to look in argv[0] instead
>>> | of p_comm?  p_comm is not changeable by the user.
>>> 
>>> You could already do this with -f. The point was to make the default case
>>> behave intuitively. Adding an option is against that. I could add backwards
>>> compatibility by checking both, but I think that in the long term this will
>>> be dangerous and confusing (since you might end up killing more than you
>>> thought you would...)
>> 
>> That (killing too much) is always true when you use something like pkill().
>> At least it is better that the 'ps | grep' I've seen many people do!
> 
> Yes, this is why it is best to not use things that kill by name from scripts.
> 
>> Is pkill() guaranteed to do an atomic traversal of the process list?
>> So it will kill something that keeps using fork() to change its pid.
> 
> I don't think our libkvm offers that.

How could you guarantee this short of moving this into the kernel so you could 
do all the comparisons while keeping all forks from happening?

Warner