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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12685 invoked from network); 16 Feb 2021 08:53:37 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 16 Feb 2021 08:53:37 -0000 Received: (qmail 6555 invoked by uid 89); 16 Feb 2021 08:54:00 -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 6548 invoked from network); 16 Feb 2021 08:54:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=k4Jb7y7qIlPusolbgJjscWw+oPt+0UxUU8+k9TyB6Kg=; b=iCH2XlnZTvexYk+aTAnTS4VXqve7j0BGq7zi+MMTZsEdhF1kxceAzNqkF7iS88C5KQ kE1ZSVvASvd5Mriq1GZgQ7702WPQCfKR/GI131JrH8TrEe0xA5yhhDxFPSWTBh1WL7cU 3KxMyxhAtgv60QIhkNYSR93ct91v31hz14hR7OZjdf4pKaFfySdgtLtv9SnjTVbqS0tU EoYiU8tpI4+hUEzTEG1q6SCeF81y+KPlCC1hzbEDhfB6RksXoTGam2aWV/3oDbz7pt6O DeSrHd+sEmBpnYzSocE+B1U1YzhA2B0fHLx4YRjHTbpaycxqXxbc8EL2T8H3GUaSaDzr NG2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to; bh=k4Jb7y7qIlPusolbgJjscWw+oPt+0UxUU8+k9TyB6Kg=; b=VSAexqg02eDaoaRfI+tkbzyamx044uNEwZF5UffmVmN4YvCOVPP8hOtAGJqcOcWhw5 KoAXVSYbiyjvZhLnlLSt7wN8g1YFUxYpAKpsvxuGdN2ZtfRX3DleT7w2VURDIUlWX8HU 91cA7J/MgGvF3HunJvaJuqXBD+LXLpDpLuV4GpmYCd9ck60xcDWuyAk6ooO3KOp9DaBc sskRu7gaGHLW//R8Gw2zD8dqcmKkZcBZOrgERYNRLLWyQgglgY4T2ymUPRwDY+4AVzL+ f6nAHx0CNdNsroqyG4RaIRPiOX+EVRPAAzDJQRGruFfVv4DQcKbTp0bjnLbJmNDAzFt0 Eqbw== X-Gm-Message-State: AOAM532hwDkqNv6i01pa04Zp7mfpbjyJM0nQGsxC0cl8k94fPmrmwUMS PlMJU3GmsWiGpPmC3Jc+KRBQuoertmE= X-Google-Smtp-Source: ABdhPJwWQsDKeGri/HdUjDr3dUAatKcNNKzR4ccdVR5JAEruRn6uc3cLWiAfCavNZQnhIV+LTffDXg== X-Received: by 2002:a92:7012:: with SMTP id l18mr2986438ilc.22.1613465612332; Tue, 16 Feb 2021 00:53:32 -0800 (PST) From: "Casper Ti. Vector" X-Google-Original-From: "Casper Ti. Vector" Date: Tue, 16 Feb 2021 16:53:23 +0800 To: supervision@list.skarnet.org Subject: Re: Some suggestions on old-fashioned usage with s6 2.10.x Message-ID: Mail-Followup-To: supervision@list.skarnet.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Mon, Feb 15, 2021 at 02:54:52PM +0000, Laurent Bercot wrote: > The options! The options need to be all compatible. :) And for > "shutdown", they would never implement a wrapper themselves, I would > have to do it for them - which is exactly what I did, although it's > a C program that actually implements shutdown, not a wrapper around an > atd program I can't assume will be present on the system. OK, now I understand their excuse. Nevertheless I still do not think all these necessarily require something like `shutdownd'; even in the absence of `atd', chainloading a backgrounding timer for `shutdown' is not a big exercise with execline (which is perhaps exactly what you have already done in `s6-linux-init-maker'). > What army? By the time the final kill happens, the service manager > has brought everything down, and shutdownd has cleaned up the scandir, > only leaving it with what *should* be restarted. You seem to think > I haven't given these basic things the two minutes of attention they > deserve. Sorry then, I did not see that in the documentation; now the scandir cleanup contributes some additional complexity. Since the mechanism behind `shutdownd' does not seem to be adequately explained at least to me, here I explicitly do not conclude this addition is worthy or not. > Conceptually, the "old-fashioned" approach may be simpler, yes. > Implementationally, I disagree that it is, and I'll give you a very > simple example to illustrate it, but it's not the only thing that > implementations must pay attention to, there are a few other quirks > that I've stumbled upon and that disappear when s6-svscan remains > pid 1 until the very end. [...] after ["wait { }"], you need to make > sure to unmount filesystems immediately [...] This is not exactly what older s6-linux-init actually do, which has been mimicked by slew. As long as the procedure between `wait { }' and `umount' does not produce orphans, the `umount' will be fine. I have noticed you saying "a shell does not give ordering guarantees when it gets a SIGCHLD", but it seems to me that the no-orphan requirement can be verified by ensuring no commands involved gets backgrounded. Of course, feel free to correct that; more importantly, may I request you to list the quirks you have encountered? Only by that may we really see how much the remaining `s6-svscan' brings, in comparison with how much it takes (see my paragraph above). > If your shutdown sequence is e.g. written in Lisp, and your Lisp > interpreter handles pid 1 duties correctly, okay, that's fair, but > that's *two* programs that need to do it, when one would be enough. [...] > The fundamental difference is that the current s6-linux-init hardcodes > a lot of things in stage 1, purposefully. Yes, it is less flexible - > though you *still* have a stage 1 hook if you really need it - but the > whole point is to make stage 1 entirely turnkey and foolproof [...] When mentioning Lisp, I did not mean to imply Lisp interpreters, but optimising Lisp compilers, which blur the border between scripts and compiled programs (cf. `fdclose' and `fd_close()'). But you have said the problem is not about scripting, so we do not disagree on this; with this background, I do not quite understand your emphasis on stage 1 in s6-linux-init -- do you mean somewhere that it prepares for `shutdownd'? > The "screwdriver and duct tape" feel does not come from the fact that > those are scripts; it comes from the fact that the scripts run in a less > forgiving environment where they have to provide the necessary guarantees > themselves, as opposed to keeping using the framework that has been > running for the whole lifetime of the system and that is still valid and > helpful, even though for once you have to interact with it and tell it > to stop supervising some services because we're shutting down - which is > the exact kind of situation the supervision API was made for. Now that scripting does not seem to be a major problem (which falsifies my previous judgement that it was; sorry for that), the only crucial issue is the costs and benefits of the supervision tree on halting. So may I again request you to spare some time to explain the detailed workflow behind `shutdownd', and the actual quirks that a remaining `s6-svscan' helps to solve? Perhaps current s6-linux-init and older s6-linux-init (with derivatives like slew) are just software that suit different niches (eg. sysvinit/systemd-minded audience vs. those who accept daemontools-ish software well), which would be perfectly fine. > I also disagree that the script approach is shorter and/or clearer. > It may be clearer to people who read a script better than a doc page > (or C code), but I don't think it should matter as long as the doc is > accurate; if it's not, that's what should be fixed. And the source code > may be shorter with a scripted stage 1, for sure, but the code paths > taken by the CPU are way shorter with the C version, and make fewer > assumptions. I'm confident that the current s6-linux-init breaks in > significantly fewer situations than its previous incarnation. Then the `shutdownd' documentation might need to be fixed; BTW, the "Is it possible to write stage {1,3} init in a scripting language?" sections from `s6-svscan-1.html' have not seen real changes since 2014 ;) -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2022.09.20) 7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C