From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id CBF3C25CEE for ; Sat, 18 Jan 2025 12:17:18 +0100 (CET) Received: (qmail 5778 invoked by uid 550); 18 Jan 2025 11:17:12 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com x-ms-reactions: disallow Received: (qmail 5748 invoked from network); 18 Jan 2025 11:17:12 -0000 Date: Sat, 18 Jan 2025 06:17:02 -0500 From: Rich Felker To: Askar Safin Cc: musl Message-ID: <20250118111702.GM10433@brightrain.aerifal.cx> References: <19471652a7a.50e9fe137311.5385327542827515244@zohomail.com> <20250117063709.GJ10433@brightrain.aerifal.cx> <1947568343c.4b19ad8c16088.1387564150395328587@zohomail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1947568343c.4b19ad8c16088.1387564150395328587@zohomail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [bug] Ctrl-Z when process is doing posix_spawn makes the process hard to kill On Fri, Jan 17, 2025 at 09:55:50PM +0400, Askar Safin wrote: > Thanks a lot for answer! > > ---- On Fri, 17 Jan 2025 10:37:09 +0400 Rich Felker wrote --- > > Note that SIGSTOP, which is not blockable interceptible or ignorable, > > can't be handled this way, but the pid has not yet leaked to anything > > at this point, so the only way SIGSTOP can be generated is by a badly > > behaved program signaling random pids, which is not a case that needs > > to be handled gracefully. > > But what if somebody sends SIGSTOP to whole process group using kill(2)? > > The bug is not reproducible with fork. Maybe this is kernel bug and should be > forwarded there instead? I don't understand what you think the kernel bug is. AFAICT it's behaving exactly as it should. The spawn impl just isn't using the kernel primitives exactly right. Since SIGSTOP is an issue, I don't think my previous idea of using no-op signal handlers makes sense. We'll have to handle an unblockable stop situation anyway so might as well use the same for blockable stops. So, I think the parent, while waiting for the fd close event from the child, also needs to watch for child status change to stopped, and if this happens, send SIGCONT. This is unfortunately gratuitously difficult, since we don't have a primitive to wait for fd-activity-or-pid-activity short of depending on pidf (if this even works; does pidfd poll readable for transition to stopped state?). If there is a working pidfd approach, I guess we should use that, and fallback to polling with short timeout and doing a waitpid/WNOHANG between polls if pidfd isn't obtainable. Rich