From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,NICE_REPLY_A autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29073 invoked from network); 3 Dec 2020 21:22:45 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 3 Dec 2020 21:22:45 -0000 Received: (qmail 24626 invoked by uid 89); 3 Dec 2020 21:23:07 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Received: (qmail 24619 invoked from network); 3 Dec 2020 21:23:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=obarun.org; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References: In-Reply-To:Message-Id:Subject:Cc:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=YImEC7ABw/nUtQKMmQwa+BFf8ZnewUnRucTE8Rl9Y/A=; b=paNRL4tGWBCN5e3a7ccR2VQfAj TuenVymxqftgT/HsQdMgboEnv7YLkShQkqQg5uAl8XrlucGb8DoTJy1ULy5WII9wLF43jlttN5rev xgES90OFHU9onfp+nU9tmwATN3XOSbNtLhz8OsFSzcbLS+5Q+aVNcjynX75fzlbly3bdaEwspsjkH Pyd642W02JlASV3MdWjYiRagJz6wCYLAL+uJc8VK12nl8+Hw3J2r4d1j84wxp5+DtzlNluuHNV4fb KIgRUZsY79BQ6paQP2muPtodA8c47Miach6DRSV7ZuZLs5Ns38jP3TpMdKe0aVx1ap8NYIp8aGHYY ior54Tzw==; Date: Fri, 4 Dec 2020 08:25:03 +1100 From: eric vidal To: supervision@list.skarnet.org Cc: "Laurent Bercot" Subject: Re: s6-supervise: use of nosetsid Message-Id: <20201204082503.f8ef16cb12b46ff68e4099c1@obarun.org> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sv26.byethost26.org X-AntiAbuse: Original Domain - list.skarnet.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - obarun.org X-Get-Message-Sender-Via: sv26.byethost26.org: authenticated_id: eric@obarun.org X-Authenticated-Sender: sv26.byethost26.org: eric@obarun.org X-Source: X-Source-Args: X-Source-Dir: On Thu, 03 Dec 2020 16:46:58 +0000 "Laurent Bercot" wrote: > > Hello, > > The next version of s6 will be a major bump, with a few long-awaited > QoL changes - mainly a thorough cleanup of how s6-svscan handles > signals and the various commands sent by s6-svscanctl, but also some > goodies that you should like. :) > > One issue that has been often reported by users is that when they > try running s6-svscan in a terminal, and then ^C to kill it, the > services remain running. This is intentional, because supervision > suites are designed to isolate processes from anything accidental that > could bring them down, and in particular services should normally > survive supervisor death - but so far there has been many more > instances of people having trouble with that behaviour than instances > of s6-supervise accidentally dying. > > I have previously added the "nosetsid" feature to s6-supervise, to > address the issue: having a "nosetsid" file in a service directory > prevents the service from being started as a session leader, it starts > in the same session as the supervision tree (and, if the nosetsid file > is empty, in the same process group). So when people want to manually > test a supervision tree, they can have nosetsid files in their test > service directories, and ^C will send a SIGINT to all the processes > including the services, so everything will die, which is what they > want. > > There are two problems with the nosetsid approach: > > - Oftentimes, users are not aware of the existence of nosetsid, and > still experience the issue. It's almost an s6 FAQ at this point. > - The nosetsid functionality is inherently a risk: it puts the > whole supervision tree at the mercy of a misbehaved service that would > send a signal to its whole process group. There is a reason why > s6-supervise normally starts services in a different session, and > nosetsid bypasses that safety measure. > > So I am thinking of another approach to make s6 friendlier to users > who would - despite it not being recommended behaviour - test a > supervision tree in a terminal: have s6-supervise handle SIGINT and > make it kill its service before exiting. That would ensure that ^C > cleans up everything. > > This approach has the drawback of making services a little less > resilient, but s6-supervise getting a SIGINT should *only* happen in > the case of someone running a supervision tree in a terminal, which > is absolutely not something that should exist in production, so it's > probably not a big concern. However, it comes with a major advantage: > it removes the original reason for the addition of nosetsid. > So, with the change to ^C handling, I am considering removing the > dangerous nosetsid functionality entirely. > > Hence, my question to users: do you have a *valid* reason to use > nosetsid files in your service directories? Are there use cases for > nosetsid that I have not thought about, and that would make using s6 > impractical if the functionality were to be removed? > > Thanks in advance for your input. > > -- > Laurent > I never used the nosetsid file. Even for people who want to test a service with a fresh scandir from a terminal, i provide the necessary tools to properly start and stop the scandir without the need to hit the ^C key. So no valid reason from my part to use this files. Your commit https://github.com/skarnet/s6/commit/bdef68e12278ddfc5080732bd3b28dd5135c9d3a simplify a lot the s6-svscan interface which is a great thing. -- eric vidal