On 2014-03-26 13:31, sven falempin wrote: > On Wed, Mar 26, 2014 at 1:55 PM, Jan Stary <h...@stare.cz> wrote: > >> On Mar 26 09:29:16, sven.falem...@gmail.com [1]wrote: >> >>> Listing process takes also times, >> pkill doesn't list anything. No really, read the manpage. >>
>>> and deleting the listed PID may also end in deleting another process in a race condition case. Or is there some kind of smart lock inside pkill ? >> No. > > lets talk about /proc :p Quoting from http://en.wikipedia.org/wiki/Everything_is_a_file, "However, this is typically not considered a fast or portable approach and should be avoided in most code." I personally don't have a problem with, say, /proc being the canonical source of process data instead of whatever ps(1) calls, but that takes us out of the traditional realm of UNIX and into Plan9 territory. Also note the existence of /dev/mem and /dev/kmem... technically you could therefore say that *everything* is accessible through a file :-). Peeking and pokeing individual bytes in memory has long since been relegated to device drivers because it's a PITA. Using pkill(1) correctly should be more efficient than opening a file, reading its contents, then passing those as an argument to kill(1). Of interest, it appears that to use pkill(1) to signal dhclient(8), in the case where you could have multiple dhclient(8) instances running, you must use the "-f" flag to pkill and match "dhclient: <ifname>", or you'll signal every dhclient instance on the system. (Yes, I have legitimate cases where I have dhclient running on two or more interfaces.) The privileged process of dhclient does not appear to share the same process group id as the other two processes, and I can't see any way of linking them through PPIDs, process groups, tty groups, or anything else like that. I'd like to know if I'm missing something here... -Adam Links: ------ [1] mailto:sven.falem...@gmail.com
