From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by sourceware.org (Postfix) with ESMTPS id 520463857C40 for ; Mon, 22 Aug 2022 17:00:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 520463857C40 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sunshowers.io Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sunshowers.io Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 42BF15C0140; Mon, 22 Aug 2022 13:00:21 -0400 (EDT) Received: from imap49 ([10.202.2.99]) by compute3.internal (MEProxy); Mon, 22 Aug 2022 13:00:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunshowers.io; h=cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1661187621; x=1661274021; bh=FD7hqhqAwz vKTdEKkWsqKM8rqIstWluYnaL8FbZTtpU=; b=eQuWLANa54/yHMRSx22NtooAWk xVH/jkzBCtgGj0zLf3xMUuP8XEl0NyxjKR1yyQwN+xJP+N6F1fzMbNVwywu71V7+ Z/ZZCcHcjG3auuw9+T30qwjVNu54VrNEs8y5CrHzlZpgnnSYpCaPyyoKMDqZIM+R QV1WlvOi8a2M4YBMD4PrXcJAPuswcSC/usyeaB5zrHfC4lpUPR24stlItEZ3LlBa pRLhaHwkwR49wLq+GLbLK2Yjx2nROxKQcldDE7Xi5sAJnyxCV9wrxLXTWL3VQOLj HWMHe6h184b+avYtX8qMj4ZVA2KNlfLpK3SoPdMWqEJgrBlZ1FxO3IXR1sXw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1661187621; x=1661274021; bh=FD7hqhqAwzvKTdEKkWsqKM8rqIst WluYnaL8FbZTtpU=; b=rXFd5eemrdLZMDgu3l6+uW8SLcv9E/OPaCqo0szhHCNy kPxpERxkACUXiozfPygSinIL0vWa33FzLDgHldvDYhHC6pH4a7h8ACtBqsIcCJoG I/wCb9z87Zt7OGi5ml/L8sIIcJ/SUMvE7RYOxGrXd5aRzLY1PPLo8nTNl8CWt/M/ HOUbgfjVif36at6f7Kc98LpHF/SE28GpX54xcc5c7WrHpFvC5lAOC/GAUKl5f8i+ 3xnZ2H/Nqgw7tKb/svkhkb2naDih+zOSZ7gEZEsefVe9E7nmGfFZANOx/HQjRGdU JfOnyEwJT/O9Y1ktpVqqOFvwHtB7xpLmjBqrMAW3YA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdeijedguddtlecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpeftrghi nhcuoehglhhisggtsehsuhhnshhhohifvghrshdrihhoqeenucggtffrrghtthgvrhhnpe duleetteduvdeuudelgffhjefgheeiueejfedvieffgeefkefhgfeggfdtvdehffenucff ohhmrghinhepghhnuhdrohhrghdpghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepghhlihgstgesshhunhhshhhofigv rhhsrdhioh X-ME-Proxy: Feedback-ID: i552946fd:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 295D615A008B; Mon, 22 Aug 2022 13:00:21 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-841-g7899e99a45-fm-20220811.002-g7899e99a Mime-Version: 1.0 Message-Id: <64917a2f-788b-4695-b799-63bbb8a4873f@www.fastmail.com> In-Reply-To: <7727e4de-a8da-1e6b-4d7c-68a132750996@linaro.org> References: <2921668c-773e-465d-9480-0abb6f979bf9@www.fastmail.com> <7727e4de-a8da-1e6b-4d7c-68a132750996@linaro.org> Date: Mon, 22 Aug 2022 10:00:00 -0700 From: Rain To: "Adhemerval Zanella Netto" , libc-help@sourceware.org Subject: Re: posix_spawn: parent can get stuck in uninterruptible sleep if child receives SIGTSTP early enough Content-Type: text/plain X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2022 17:00:25 -0000 On Mon, Aug 22, 2022, at 09:51, Adhemerval Zanella Netto wrote: >> --- >> >> Based on these backtraces and reading the source code, here's what I believe is happening: >> >> 1. The parent calls __posix_spawnp, which in turn calls __spawni and __spawnix. >> 2. The parent calls clone3 and enters uninterruptible sleep. >> 3. The child enters __spawni_child and blocks all incoming signals. > > In fact glibc do not block, but rather set all handlers to either SIG_DFL > if is not SIG_IGN, or SIG_DFL if POSIX_SPAWN_SETSIGDEF is set. However > it does not matter for SIGSTOP since we can not set it to SIG_IGN. > >> ---> 4. At this point the child receives a SIGTSTP signal. <--- >> 5. The child unblocks signals by calling sigprocmask/pthread_sigmask. >> 6. At this point the SIGTSTP is delivered to the child. > > Afaik SIGSTOP is not synchronous and can be delivered any time during process > execution. Thank you for the response! To be clear, I'm referring to SIGTSTP (Ctrl+Z) [1], not SIGSTOP. I understand that SIGSTOP cannot be blocked. However, SIGTSTP (which is a different signal which can be blocked) is what I'm concerned about. > >> 7. However, the clone hasn't exited in the parent and so it remains stuck in the clone3 syscall until the child receives a SIGCONT. >> >> I'm not sure what a reasonable way to handle this would be on the part of my CLI tool. The tool currently just gets stuck in uninterruptible sleep, resulting in a bad user experience. > > Reading through both your twitter discussion and the bug report against your > tool [1] I think it is outside posix_spawn specification on how to handle > SIGSTOP for the helper process itself in the tiny window between process > creation and the setpgid. > >> >> Here are solutions I've thought about that don't seem to work (please correct me if I'm wrong!) >> 1. Setting the signal mask to include SIGTSTP. I do want to be able to send the child SIGTSTP after the clone(), and in my case the child is a third-party process so I can't depend on it to reset the signal mask. >> 2. Spawning a stub process that execves the real child. It seems like the same issue exists when the main process calls the stub process, if I'm understanding the code correctly, so this won't help. >> >> ... though now as I'm writing this email out, maybe one solution is: >> >> * my tool spawns a stub process with SIGTSTP masked. >> * the subprocess unmasks SIGTSTP (so it could receive the SIGTSTP here, but at least it won't block the parent process), then execves the third-party process. >> >> Is that the solution you would recommend? > > I am not sure this would work, since SIGSTOP cannot be caught, blocked, or > ignored. What I think if might work is to spawn a stub process and make > it a new session leader with setsid so it will not have a controlling > terminal. The stub process will be responsible to spawn new processes, > so any interaction with the controlling terminal (the CTRL+Z) won't affected > the posix_spawn helper thread. That is definitely an interesting solution. However, is it necessary given that Ctrl+Z is actually SIGTSTP, which can be blocked? Thanks again. [1] https://www.gnu.org/software/libc/manual/html_node/Job-Control-Signals.html > > You will probably need to open the controlling terminal in raw mode so you > can catch ctrl-z and pass along the expected process groups. > >> >> Thanks. > > > [1] https://github.com/nextest-rs/nextest/pull/470#issue-1338100182 -- Rain (they/she)