From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10285 Path: news.gmane.org!not-for-mail From: Igmar Palsenberg Newsgroups: gmane.linux.lib.musl.general Subject: Re: abort() PID 1 Date: Mon, 4 Jul 2016 10:28:22 +0200 (CEST) Message-ID: References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1467620907 543 80.91.229.3 (4 Jul 2016 08:28:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Jul 2016 08:28:27 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-10298-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jul 04 10:28:14 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1bJzEV-0001v4-KR for gllmg-musl@m.gmane.org; Mon, 04 Jul 2016 10:27:59 +0200 Original-Received: (qmail 12281 invoked by uid 550); 4 Jul 2016 08:27:57 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 12261 invoked from network); 4 Jul 2016 08:27:56 -0000 DKIM-Filter: OpenDKIM Filter v2.10.3 s1.palsenberg.com u648SMDQ029577 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=palsenberg.com; s=s1; t=1467620903; bh=6PBFbUelThoGUa8xkCj8tpuj2SJpoJS/xGvvLCM5KvY=; h=Date:From:To:Subject:In-Reply-To:References:From; b=hsurk0Zj+RaD9ENYQudd8VccrBZTtyAzN6B+9SZtA+jTpFGFJw629EpqQe0zgNlmo a7oCzzs+2Gp3yVZOc1+VP3hVry4JtHHNWKiupC+tEB7rudh0P5Kn8xriRDVg092eKs rZR0V704wzqXfI6Spvuh//bFi7eMUQtDsZmZKAAE= In-Reply-To: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.5.16 (s1.palsenberg.com [127.0.0.1]); Mon, 04 Jul 2016 10:28:22 +0200 (CEST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on s1.palsenberg.com Xref: news.gmane.org gmane.linux.lib.musl.general:10285 Archived-At: > The recent thread about abort() and PID 1 left me in a state of > confusion, in a matter I thought was clear enough: > > What I thought I understood: > > - the kernel will not deliver any signal to process 1, unless a signal > handler for that particular signal has been installed > > -if process 1 calls abort() (regardless of what purpose that would fill), then: > > - if a handler was setup, it should be done whatever the handler does > > - if a handler was not setup, nothing should happen (as in: > process didn't receive any signal at all) Pid 1 can ignore sigkill / sigstop. "Normal" processes can't. "Normal" processes have defaults handling signals, pid 1 ignores all by default, unless it instructs the kernel it wants to receive it. > > What the standards say: > > (http://pubs.opengroup.org/onlinepubs/9699919799/) > > "The SIGABRT signal shall be sent to the calling process as if by > means of raise() with the argument SIGABRT." > > "The effect of the raise() function shall be equivalent to calling: > > pthread_kill(pthread_self(), sig);" > > man raise(3): > The raise() function sends a signal to the caling process or > thread. In a single-threaded program it is equivalent to > kill(getpid(), sig); > > So, what should " kill(1, SIGABRT)" do? It doesn't seem ambiguous to > me. IOW, there's nothing special about SIGABRT regarding PID 1. The "problem" in this case is that the "normal" abort() sends a SIGABRT, if that doesn't work, unblocks signals and retries. While that works with "normal" processes, it doesn't work with pid 1, because the default action on that process for SIGABRT isn't terminate. Hence the infinite loop you see. IMHO, we should leave this as it is, unless the abort() call fails to successfully terminate the process on non-pid 1 processes. That is a bug, failing to terminate pid 1 isn't. Igmar