From owner-freebsd-hackers@freebsd.org Sun Mar 5 21:09:19 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 247E2CFAECE for ; Sun, 5 Mar 2017 21:09:19 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.webweaving.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C63A91F0D for ; Sun, 5 Mar 2017 21:09:18 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from [10.11.0.204] (5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id v25L7rV4001677 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 5 Mar 2017 22:07:53 +0100 (CET) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20] claimed to be [10.11.0.204] From: Dirk-Willem van Gulik Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: kill -0 --- side effect or supported Date: Sun, 5 Mar 2017 22:08:01 +0100 In-Reply-To: <35C6F2AA-309E-4D58-8191-AB99F0195BEC@gmail.com> Cc: "Rodney W. Grimes" , freebsd-hackers@freebsd.org To: "Ngie Cooper (yaneurabeya)" References: <201703032230.v23MUg5b072955@pdx.rh.CN85.dnsmgr.net> <35C6F2AA-309E-4D58-8191-AB99F0195BEC@gmail.com> X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (weser.webweaving.org [148.251.234.232]); Sun, 05 Mar 2017 22:07:54 +0100 (CET) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 21:09:19 -0000 > On 3 Mar 2017, at 23:42, Ngie Cooper (yaneurabeya) = wrote: >=20 >>=20 >> On Mar 3, 2017, at 14:30, Rodney W. Grimes = wrote: >>=20 >> -- Start of PGP signed section. >> [ Charset UTF-8 unsupported, converting... ] >>>=20 >>>> On Mar 3, 2017, at 14:12, Dirk-Willem van Gulik = wrote: >>>>=20 >>>> I regularly use 'kill -0 ' on FreeBSD as a way to test if a = certain process is still running (but without actually sending the = signal). And I think it has worked reliably since the mid 80's. >>>>=20 >>>> Is it actually a properly supported use - as I recently happened to = notice that it does not seem to be all that documented in kill( >>>=20 >>> It better work. I have code that relies on it :)? >>>=20 >>> It does work as you noted, according to truss: >>>=20 >>> # sudo truss -ff kill -0 1 2>&1 >>> ... >>> 79940: kill(1,0) =3D 0 (0x0) >>> ? >>> # >>>=20 >>> As noted in kill(2), this is one of the valid values: >>>=20 >>> a group of processes. The sig argument may be one of the signals >>> specified in sigaction(2) or it may be 0, in which case error = checking is >> ^^^^^^^^^^^^^^^^ >>=20 >> That bit of information should be promoted from kill(2) to kill(1) by >> adding 0 to the list as ?. >=20 > Actually=E2=80=A6 it is mentioned in kill(1) =E2=80=94 you just have = to read between the lines: >=20 > -signal_number > A non-negative decimal integer, specifying the signal to = be sent > instead of the default TERM. >=20 > 0 is technically a non-negative real number. >=20 > It might be a good idea to clarify this point/behavior by pointing to = kill(2) for the signal behavior/description noted above. Posix @ Opengroup says: = http://pubs.opengroup.org/onlinepubs/009695399/functions/kill.html The kill() function shall send a signal to a process or a group = of processes specified by pid. The signal to be sent is specified by sig = and is either one from the list given in or 0. If sig is 0 = (the null signal), error checking is performed but no signal is actually = sent. The null signal can be used to check the validity of pid. I guess this could be added - with perhaps the note/warning on the = 'zombie' processes - as this is subtly different between unixes. Dw