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=DKIM_SIGNED,DKIM_VALID autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 17172 invoked from network); 29 Mar 2023 20:20:31 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 29 Mar 2023 20:20:31 -0000 Received: from pb-smtp2.pobox.com ([64.147.108.71]) by 9front; Wed Mar 29 16:15:49 -0400 2023 Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 37DAE193783 for <9front@9front.org>; Wed, 29 Mar 2023 16:15:46 -0400 (EDT) (envelope-from unobe@cpan.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h=message-id :to:subject:date:from:in-reply-to:mime-version:content-type :content-transfer-encoding; s=sasl; bh=/HZJWKfmukEYawOrqBtCJgi0F 1d3T0Yb+0QdUPE3lY8=; b=ii2ZoccGhelX7yVCkDIe4uYvOStxVIDcd5LY0wDr9 TlGoPdKjlaXxOcqSSoJwS5+YxQyM+VytAoHzVZz9blA2NKekBEIBS4au/gsTtWXg e6XUgr65tD87EPB3ihAiz+51dzh+GUx0sUPnGCMdc3b8rXdRg22frIenqYTBsx8n /0= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 307C2193782 for <9front@9front.org>; Wed, 29 Mar 2023 16:15:46 -0400 (EDT) (envelope-from unobe@cpan.org) Received: from strider.localdomain (unknown [75.204.169.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 6B12E193781 for <9front@9front.org>; Wed, 29 Mar 2023 16:15:45 -0400 (EDT) (envelope-from unobe@cpan.org) Message-ID: <7DE8FD327C993A1A92A480A88E8B9D4E@smtp.pobox.com> To: 9front@9front.org Date: Wed, 29 Mar 2023 13:15:43 -0700 From: unobe@cpan.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 7CE8D3C2-CE6E-11ED-8AD6-307A8E0A682E-09620299!pb-smtp2.pobox.com List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: asynchronous strategy Subject: Re: [9front] srv(3) clone and srvid Reply-To: 9front@9front.org Precedence: bulk Quoth ori@eigenstate.org: > Quoth Jacob Moody : > > Yes, clone works like how it does in /net, the board is only open for as long > > as you have the fd open. So you cat'd it which opened it, read the new id, then closed > > it deallocating the child srv. You need to keep the fd open for the length of time you > > use the child srv, Or if you wish to 'pin' the child srv you can stash the clone fd itself > > as a file in the child srv. This will keep the child srv around until you remove the pinned > > clone fd. Thank you Moody. I'm still misunderstanding something because I would have that: bind -c '#s20' /srv when /srv/20 isn't available would have failed somehow, since the man page states: As a convention, /lib/namespace accepts the path to the service directory from the environ- ment variable $srvspec, making it possible to start a new namespace using a specific service directory as a starting point. But for comparison, this has no failure either: bind '#l20' /net so I still need to wrap my head around something. > for an example of how it's used on shithub: > > <[3]/srv/clone{ > d=`{<[0=3]read} > bind /srv/$d /srv > # ugly, but we don't want to leak the clone fd into > # procs that may stick around, so write over fd3 again > <[3=0]{ > rfork n > bind /usr/web /mnt/static > execfs -m /usr/web /sys/lib/tcp80/gitrules > bind /mnt/static /usr/web/static > rfork n > cd / > exec /bin/tcp80 > } > } > Thank you Ori, that was very helpful. I was surprised to see that the file is left open when there's an rc error: cpu% lc /srv acme.glenn.3372 cons hjfs.cmd rio.glenn.504 acme.glenn.908 cs mntexport rio.glenn.836 boot dns pin-glenn slashmnt clone factotum plumb.glenn.495 slashn cpu%