From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2655 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Guillermo Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: s6-linux-init: Actions after unmounting filesystems Date: Sun, 18 Aug 2019 16:28:40 -0300 Message-ID: References: <20190818040925.yqy4nm7cwsnrtyjl@caspervector> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="7806"; mail-complaints-to="usenet@blaine.gmane.org" To: Supervision Original-X-From: supervision-return-2245-gcsg-supervision=m.gmane.org@list.skarnet.org Sun Aug 18 21:28: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 1hzQrG-0001th-Hr for gcsg-supervision@m.gmane.org; Sun, 18 Aug 2019 21:28:54 +0200 Original-Received: (qmail 6650 invoked by uid 89); 18 Aug 2019 19:29: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 6643 invoked from network); 18 Aug 2019 19:29:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=jNJumi8z8SntHP9IDre5wloIPt5BB9ehfS62U3Rvm7s=; b=o4oVzB3wVPoTD/FDENvyV6IkBPcGcvctiMm1Z8r7EIKneV3bxf85l4YAIy2Mvm7Hi6 XtUlzq56udQsNnP/AOdAfStBDTGvFyg/jK8hOrE8gAzMy+jaDmHrqsSXtkxkllmSoAmQ SM4Ih4trVfTab+kZBLSI4V9xxsoESlf68/xRRt7jDv0oV+xETW01y3DPQYNRS504L9yj 0JyizX5AGK5aOjBUsVHV6OaOpNS0ykZjV9AbTP91y/os9nmYMgqOBbwWl9i1BX7veo7Q cG2lEIoPhBhfxIhSm+oI7bOjMsDAJKqLwWj9u2gXK8ZeFN58mHjdg9H0u/U1tCNOdnsR ftGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=jNJumi8z8SntHP9IDre5wloIPt5BB9ehfS62U3Rvm7s=; b=TUR5V5k7qf9L4xu+iV/vcEYXCQvV9B2FjUFrjmL7bwRnuke769u4LVqrJVCB2OPvpj WUGUlqjwr/elLFWXuX6qQMHDLTgRk+Vl/6eRzR9mhR3UOXDO44XZBloin8XOGBLEBhJ1 ise3P5HmSAcUi36oeOxJ0zTIzimDWksS+B8PJrp5GfbObEcEvAaJoYE9QGy6Dyo98+o+ wCPZuqm4keyKcjRiaFFKiC64hfcJPfTJaMGNt5lngqzxspEoKPzMvT4DxWF5TuhUqgIL HNrN9IiQppzxfc2wYqOAqtoU6UJZSvW2s/q8I8Mg0pszXWu59vSR+dg6DxHdunj3Ds54 6Syw== X-Gm-Message-State: APjAAAWmZImDlIchBiZnO0DNM5F/RmLtCEPwXx2YKosnj47TqtuuDXMU FGDYqy8QE17/+RGXPRXZh2PXCXpTBJRpJTFHkygF2A== X-Google-Smtp-Source: APXvYqwfpVQ3QyL88UMiUs/JyW9Sp9UtlACmxn9yp3WCKBNZ0C996wu8AFetxf1g4Cd46ACHXMqF4OaCgq4pTk3hZc8= X-Received: by 2002:a6b:e317:: with SMTP id u23mr23572119ioc.38.1566156532374; Sun, 18 Aug 2019 12:28:52 -0700 (PDT) In-Reply-To: Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2655 Archived-At: El dom., 18 ago. 2019 a las 15:36, Laurent Bercot escribi=C3=B3: > > >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. > > Are there systems in the real world that actually work like that? That > need pivoting into a "shutdownramfs" in order to be able to unmount the > rootfs and perform teardown operations on it? This is doable, of course, > but sounds too complex and too brittle. You'd need more than a fsck to > recover after a power loss, for instance. I know that there are people that have the rootfs on an LVM logical volume or a LUKS encrypted volume, yes. However, those are specialized setups. I don't use one myself, I think they are risky, and I don't know the details, but I think they are handled with a (mandatory) initramfs. Perhaps someone else knows this better. Our friends from the systemd project have thought of that as well (the 'shutdownramfs' would be the initramfs that is kept mounted at /run/initramfs): * https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface But I think of this as a separate problem, that maybe also means revisiting the decision of not having s6-svscan do its finish procedure. I didn't want to mention all the complicated cases at once :) > Now the fun part for me is to find a way for s6-l-i-umountall to > leave the proper filesystems mounted. It's not as straightforward as > it seems: if /dev is a symlink to, say, /mnt/tmpfs/dev, then you want > to keep /mnt/tmpfs/dev, even if it means you have to keep /mnt/tmpfs. > But if you have a second dev mount on /usr/local/mychroot/dev, then > you want to unmount that one, so you can unmount /usr/local. I suppose > I can count the number of devtmpfs, procfs and sysfs, and only keep > one of each (the first that was mounted), but I have to think more > about it to make sure it catches everything. Why not just leaving all of them alone? s6-linux-init-umountall already warns about, but then just ignores, umount(2) failures. What happens if you try to unmount /mnt/tmpfs, and you have a devtmpfs mounted on /mnt/tmpfs/dev that you have previously skipped? G.