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.0 required=5.0 tests=T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 20868 invoked from network); 15 Feb 2022 09:58:41 -0000 Received: from 4ess.inri.net (216.126.196.42) by inbox.vuxu.org with ESMTPUTF8; 15 Feb 2022 09:58:41 -0000 Received: from odoacer.turtle-trading.net ([93.241.193.16]) by 4ess; Mon Feb 14 14:22:53 -0500 2022 Received: from zenobia.turtle-trading.net ([192.168.2.111]) by odoacer.turtle-trading.net with esmtp (Exim 4.80) (envelope-from ) id 1nJgfg-0002UZ-Ep; Mon, 14 Feb 2022 20:06:00 +0100 Received: from benny by zenobia.turtle-trading.net with local (Exim 4.94.2) (envelope-from ) id 1nJgfg-0008K3-6j; Mon, 14 Feb 2022 20:06:00 +0100 From: Benjamin Riefenstahl To: Steve Simon Cc: 9front@9front.org References: <875ypmd3er.fsf@turtle-trading.net> <2B66F3F0-47FA-4FC4-B6CD-ECDDC16A514D@quintile.net> <87iltlmxul.fsf@turtle-trading.net> Date: Mon, 14 Feb 2022 20:06:00 +0100 In-Reply-To: <87iltlmxul.fsf@turtle-trading.net> (Benjamin Riefenstahl's message of "Fri, 11 Feb 2022 12:44:34 +0100") Message-ID: <87r185s1yf.fsf@turtle-trading.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: AJAX over SOAP deep-learning shader-oriented controller Subject: Re: [9front] Invers of partfs Reply-To: 9front@9front.org Precedence: bulk Hi Steve, all. > Steve Simon writes: >> probably the easiest would be to put your tests in a script with >> =E2=80=9Crfork ne=E2=80=9D at the top. >> >> this will ensure that when your script ends the namespace and >> environment will evaporate. partfs will also close as its input is >> closed as part of the namspace going. Interestingly, partfs (i.e. the block device) and the filesystem mount itself do go away as expected, but the cwfs64x processes (some 20 or 21 processes) do not. They require "echo halt >> /srv/servicename" to end themself. Is that expected or is it a bug? What I do, just for background: I have a diskimage with partitions for a cwfs file system on it. I run partfs, cwfs64x, and mount to get at the contents of the file system. When I run that inside a process with "rfork ne", the service created by cwfs64x is visible from another rio window, but not the block device created by partfs and not the mounted filesystem. So it's consistent in that way. benny