From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2567 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Casper Ti. Vector" Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: Update on the progress of slew development Date: Sat, 4 May 2019 14:07:04 +0800 Message-ID: <20190504060704.GA27290@CasperVector> References: <20190317132532.GA22622@CasperVector> <20190317153002.52c28cf7@dickeberta> <20190319124239.GA26884@CasperVector> <20190319165853.6bb9f44a@flunder> <20190320051439.GA7636@CasperVector> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="75319"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.11.3 (2019-02-01) To: supervision@list.skarnet.org Original-X-From: supervision-return-2157-gcsg-supervision=m.gmane.org@list.skarnet.org Sat May 04 08:07:13 2019 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hMnpJ-000JNW-0J for gcsg-supervision@m.gmane.org; Sat, 04 May 2019 08:07:13 +0200 Original-Received: (qmail 24037 invoked by uid 89); 4 May 2019 06:07:37 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Original-Received: (qmail 24030 invoked from network); 4 May 2019 06:07:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=KIhG3yYzXIzrh92BhJgZB+ecfW0gHfy+l59VFq0QyN8=; b=NRkN+/M1SsueKEjTEHq/zzkXYqxct3hMrGVvD9oljpKwaGxCKb7rGM9LLCjlBtxt8r NX6DSznWZwGJgbV5rtO8Eq842cU6mTa3cmfASmqdfUexFsPSL4iUuJdDsRQPi6zY8/Mq cfFqekfqEwVVSqIh4iWPwCUK28OyeEffAIcxAGpJc+Ex7FobB9KorH6e3QshqiFlX9cy MFXeRyA48Bce15SiwXP1v9elHVEehVPbdYFkAeK4kI9aO37bVzXPGhnCcJasluFiOejV 7fYZd+yLLXuAAxQQusBJ27ciSbpMJy7+eAYMnvWRmVPzv5nuFXZTrDE/S8sdElvXz6VC tp1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=KIhG3yYzXIzrh92BhJgZB+ecfW0gHfy+l59VFq0QyN8=; b=fO79I5WUa4YKfc907IbdgPXDueXyua9cAPNaZVzSES2WcQoJg+2LpJr6JcBcrfk3iQ qSCFBlvLKfZpQsQUpitA/rUXhcUD0LdQ2mXhwqRV2U4o+4PiSYBNNM26DE0gEcSf/42A yvOybzkArOWvOVqEjU8GaY6ymQop7I9+SpkfYSi+SOdp182oyulWjo8UaQl59oS5l9/4 3DTUKYqCsJDkQGrxU8gjfX/pbnLlJKNAxktPefJmBtZm531JvIsioDe+VMQHNG7c67rc e+Py5IDLGYstT/XDMwLYyrNd9eu/Xu3lpgLM7/ikxEAxLYz6C251mNTamzptlCSMpy+J cl4Q== X-Gm-Message-State: APjAAAXBIsrI+8LfmizuTvpd0jA2XKRDLaKI+9YgLcGsaw+3v2EnZQV2 oITfyPkWH6UhHj84ETXXAlw+loA0p4s= X-Google-Smtp-Source: APXvYqxXUdBLL9G7inAn03xpiYn66mPDrVf7U2mydpphASk0WPQU7QiqKuPlWAQxe95EEKvbVW4m1g== X-Received: by 2002:a17:902:302:: with SMTP id 2mr16415309pld.232.1556950028502; Fri, 03 May 2019 23:07:08 -0700 (PDT) X-Google-Original-From: "Casper Ti. Vector" Mail-Followup-To: supervision@list.skarnet.org Content-Disposition: inline In-Reply-To: <20190320051439.GA7636@CasperVector> Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2567 Archived-At: On Wed, Mar 20, 2019 at 01:14:39PM +0800, Casper Ti. Vector wrote: > pkill(1), killall(1) and killall5(8) all retrieve a process list and > kill them one by one, instead of calling kill(-1, signal), so a race > condition can happen thats let some process escape the final SIGKILL. > Since pkill(1) and killall(1) use regex matching, the probability for > the race can be significantly larger. > > To be 100% sure no process (except for PID 1) escapes that signal, you > can use `s6-nuke' from s6-portable-utils. `kill -signal -- -1' should > theoretically do similar things, but kill(1) from coreutils and busybox > do not seem to behave in this way. Reading recent posts on this mail list, I have noticed that the sentence about kill(1) was incorrect because: * POSIX does not require `kill -signal -- -1', but just `kill -- -1' *in addition to* `kill -signal -1'. * `kill -signal -1' does do the desired job, and I erronously thought it did not, because what I tried was `{/bin/kill,busybox kill} -15 -1' in the shell of a test user, but the shell trapped SIGTERM (and Linux does not send the signal to the calling process of kill(-1, signal)). * coreutils does not implement kill(1); busybox, util-linux and procps do. Anyway, `kill -{signum,SIGNAME} -1' is required by POSIX. slew has been updated (commit 593e6174) to use kill(1), and its users no longer need to worry about the theoretical possibility about comets [1] escaping the final SIGKILL. [1] -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19) 7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C