From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2653 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Samuel Holland Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: s6-linux-init: Actions after unmounting filesystems Date: Sun, 18 Aug 2019 11:18:50 -0500 Message-ID: References: <20190818040925.yqy4nm7cwsnrtyjl@caspervector> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="62024"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 To: Laurent Bercot , supervision@list.skarnet.org Original-X-From: supervision-return-2243-gcsg-supervision=m.gmane.org@list.skarnet.org Sun Aug 18 18:18:55 2019 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hzNtO-000G3F-Md for gcsg-supervision@m.gmane.org; Sun, 18 Aug 2019 18:18:55 +0200 Original-Received: (qmail 3792 invoked by uid 89); 18 Aug 2019 16:19:20 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Original-Received: (qmail 3780 invoked from network); 18 Aug 2019 16:19:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sholland.org; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm3; bh=U AWDGIqc7i09oLqDiwhDRzFAd1gTmtFq5qSkoDpq5b8=; b=WR7ZvUXSuil22YEv1 zLsDRNfBaGarJMz64cmspONrPmXSj6x/KNQhqJtr9evjN/HT+PN2LrbJ9D086AwN Zss5IPJlER6svzPmHzzBRXE0mRksCLD+y7ZdOKMyLF3zLTAX6cc+kKMemIF8FdBz cQLo2k1y0wxmcRIkpyyclizxyYKyCnPWzytjnWNEJuZaELEJtZs6KAwTuru3AMzS JT7DUUUOyMKTsH/BFn9Ednv+wA9pWcdekGP9bkroVY+/CA0Jf9vWP0gvMPICzR0z pvaF03la1P+vNW3txkb/AseO6P4VNrj8BAKyV+WAPNPhIPgKSi7Ztnxr+IUoDq8/ qrx/Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=UAWDGIqc7i09oLqDiwhDRzFAd1gTmtFq5qSkoDpq5 b8=; b=FCYwJMnCQwXGZnzTYyb/CPysWfiJdNLNUKBkjLl9lUfqDRDR4CNYIKjY1 BXS/cBk7EgGcEcajFxA8fVjTTY2A2bDvjdvcuVQmp4Ks+QUTNHx9sv3TAFqPLDVK MvI0lzWHyrow6EancaFobga/kVQxa7LOVk0bqxzA9jsLUkPQLN7akGU6pLoSwqfj waQbq5Cl2jqAXZlxDP4Kq8+6H4/JB2hDoWrmYVrG58iMpCuJX80S/mAbAARHNtRM ZbCw4xPH7Wh3oOKEGxyJFJj0s/am6WXERvDIdIkacp7L+EKMKck+6xZYWS9bsdt0 ELpN3S5Hxp0J0e2xf2wcL5FLbfF1g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudefjedgleekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefurghmuhgvlhcujfholhhlrghnugcuoehsrghmuhgvlhes shhhohhllhgrnhgurdhorhhgqeenucfkphepjedtrddufeehrddugeekrdduhedunecurf grrhgrmhepmhgrihhlfhhrohhmpehsrghmuhgvlhesshhhohhllhgrnhgurdhorhhgnecu vehluhhsthgvrhfuihiivgeptd X-ME-Proxy: In-Reply-To: Content-Language: en-US Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2653 Archived-At: On 8/18/19 1:26 AM, Laurent Bercot wrote: >> Sorry if I read this thread too hastily, but why not just keep /proc etc >> mounted, as was seemingly the way with s6-linux-init <=v0.4.x.x (and >> therefore slew)?  Since the asymmetry is by nature, simply respecting it >> appears to be one minimalist way. > > The umount command basically performs a "umount -a". I can add a list > of filesystems that should be kept, but it's more ad-hoc code. It's > ugly. > But I guess the whole situation is ad-hoc anyway, so elegance isn't > exactly what we're going for here :/ Simply excluding filesystems doesn't help when the root filesystem is on one of these devices that needs teardown actions after being unmounted. In that case, the only workable solution is to have PID1 pivot_root() to a tmpfs with the teardown/reboot tools in it. That way you can actually fully unmount the former root filesystem. Under the current architecture, I think it is ideal to maintain the mount/unmount symmetry as much as possible. This is done in your service manager via dependencies. Have a oneshot for each filesystem that needs to be mounted, and (when applicable) have that oneshot depend on another oneshot that creates/destroys the underlying lvm/md/dm-crypt device. Then the dm device will be created before mount, and destroyed after unmount. Yes, unmounting will fail if the filesystem is in use (or already unmounted), and destroying will fail if the filesystem is still mounted, but that's okay because a `down` script should be idempotent and /always/ return success. Even when there are failures, this will minimize the number of loose ends left when shutdownd takes over. The unmounting done by shutdownd should be treated as a last resort. As a side note: what if there was a oneshot that did `kill -1` when brought down, and this oneshot depended on all of your filesystem mounts? Other than the obvious problem of s6-rc-update nuking your system, would it be possible to make s6-rc recover from being nuked and continue a shutdown? --Samuel