From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2648 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Laurent Bercot" Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: s6-linux-init: Actions after unmounting filesystems Date: Sat, 17 Aug 2019 23:01:35 +0000 Message-ID: References: Reply-To: "Laurent Bercot" Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="99963"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: eM_Client/7.2.34711.0 To: Supervision Original-X-From: supervision-return-2238-gcsg-supervision=m.gmane.org@list.skarnet.org Sun Aug 18 01:01:51 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 1hz7hn-000PsG-1B for gcsg-supervision@m.gmane.org; Sun, 18 Aug 2019 01:01:51 +0200 Original-Received: (qmail 22980 invoked by uid 89); 17 Aug 2019 23:02:14 -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 22973 invoked from network); 17 Aug 2019 23:02:14 -0000 In-Reply-To: X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduvddrudefiedgudeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecupfgfoffgtffkveetuefngfdpqfgfvfenuceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkjghfrhgfgggtgfesthhqredttderjeenucfhrhhomhepfdfnrghurhgvnhhtuceuvghrtghothdfuceoshhkrgdqshhuphgvrhhvihhsihhonhesshhkrghrnhgvthdrohhrgheqnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhhtnecuvehluhhsthgvrhfuihiivgeptd Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2648 Archived-At: >There are certain setups that require doing something after >filesystems are unmounted. Two examples are LVM logical volumes and >LUKS encrypted volumes, but I suppose there must be more cases. In any >such setup, the shutdown sequence would include a 'vgchange -a n' >command or 'cryptsetup close' command after filesystems are unmounted. Ah, of course it had to be more complex... Sigh. There are two ways to proceed here: - If a filesystem can track all the processes that have a handle on it, it is possible to have it be mounted/unmounted symmetrically by the service manager. At unmount time, kill the processes that would block the unmount operation, then perform the unmount, then run the additional commands. In that case it's all done at the service manager level, s6-linux-init doesn't have to do anything. - There could be a hook in the autogenerated stage 4 script, which runs a user-provider script, something like rc.shutdown.after-umount. I don't much like giving control to a user script at that level, when there are no services running and no mounted filesystems, possibly not even /proc or /sys, and when a hang in a user script could very well prevent a clean reboot; but it's the best I can do. Admins/distros would have to make sure the deactivate_* functions only call binaries that are on the root filesystem. Thoughts? The asymmetry of mounting and unmounting filesystems is really a pain in the ass for the design of an init/shutdown sequence. I wanted to keep the shutdown as quick, minimal, and reliable as possible, but it seems there's no way to do so with those snowflake filesystems. :/ -- Laurent