From nobody Sat Mar 26 19:39:50 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 151FD1A31D7F for ; Sat, 26 Mar 2022 19:40:01 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mail02.stack.nl (scw01.stack.nl [51.15.111.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "ecc.stack.nl", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQq6l2c8qz3FDF; Sat, 26 Mar 2022 19:39:59 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail02.stack.nl (Postfix) with ESMTP id B63F01E03CA; Sat, 26 Mar 2022 19:39:52 +0000 (UTC) Received: from mail02.stack.nl ([127.0.0.1]) by localhost (mail02.stack.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJPWAZp4sps7; Sat, 26 Mar 2022 19:39:50 +0000 (UTC) Received: from blade.stack.nl (blade.stack.nl [192.168.121.130]) by mail02.stack.nl (Postfix) with ESMTP id E67E71E03C5; Sat, 26 Mar 2022 19:39:50 +0000 (UTC) Received: by blade.stack.nl (Postfix, from userid 1677) id D6278237C50; Sat, 26 Mar 2022 20:39:50 +0100 (CET) Date: Sat, 26 Mar 2022 20:39:50 +0100 From: Jilles Tjoelker To: Ganael Laplanche Cc: Bryan Drewery , freebsd-hackers@freebsd.org Subject: Re: Our /bin/sh and process group IDs Message-ID: <20220326193950.GA1667@stack.nl> References: <48e49ad0-a12a-d10b-5867-da9736c6c1fd@martymac.org> <243ebc92-26a1-e5e7-67fe-1477ed6b5f7a@FreeBSD.org> <9745f2ef-3aae-5548-c8db-5da7d4ce11e7@martymac.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9745f2ef-3aae-5548-c8db-5da7d4ce11e7@martymac.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4KQq6l2c8qz3FDF X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of jilles@stack.nl designates 51.15.111.152 as permitted sender) smtp.mailfrom=jilles@stack.nl X-Spamd-Result: default: False [0.21 / 15.00]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jilles]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:51.15.111.152]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[stack.nl]; NEURAL_HAM_LONG(-0.99)[-0.989]; NEURAL_SPAM_MEDIUM(0.89)[0.887]; NEURAL_SPAM_SHORT(0.62)[0.616]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:51.15.0.0/17, country:FR]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, Mar 26, 2022 at 03:52:40PM +0100, Ganael Laplanche wrote: > Le 25/03/2022 à 20:13, Bryan Drewery a écrit : > Hello Bryan, > > set -m needs to be set from the parent process, not child. > Thanks for those clarifications. > Is that something required by POSIX (I could not find any documentation > about that) ? Or is it a limitation (or bug) of our implementation ? Other > shells -mostly- do not behave that way (see my original post). This appears to be a gray area, and the exact behaviour varies across shells. For example, with stty tostop in effect, sh -c '(set -m; echo "echo from background" & wait "$!"); echo "wait returns $?"' has a variety of behaviours: * with FreeBSD sh, dash and also ksh93, it prints both lines * with mksh, it only prints the "wait returns 0" line * with bash, it hangs (as expected with a new process group) I think it is definitely undesirable for set -m to have an effect across multiple levels of subshells by default, since it makes the innermost processes immediately escape from the outer process group supervision again. As it is now, FreeBSD sh has implemented this by ignoring set -m from a process other than the first process (so for example sh -c '(set -m; echo "echo from background" & wait "$!"; echo "wait returns $?")' still hangs with tostop in effect, since this particular subshell is implemented without creating a new process), but perhaps this could be extended a bit more. > > In this example test_func is a child *and* the sleep is a child which > > is also very racy. Here's a pattern I use that works: > > [...] > Unfortunately, in my case, spawn would have to be called from a sub-process > already forked (from a background function, executed as a child process) ; > so that wouldn't work either. Anyway, thanks for the hint :) A second workaround is to start a new instance of sh. -- Jilles Tjoelker