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.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, NICE_REPLY_A autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 18862 invoked from network); 29 Mar 2023 20:33:41 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 29 Mar 2023 20:33:41 -0000 Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Wed Mar 29 16:32:02 -0400 2023 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org; s=20200506; t=1680122265; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1iURx8yqYs6CFSJ39XKIQ4meSoynvLy412+gTbusDSQ=; b=Kc3+H1P72FZfBwfdJXnwvkc7a3H9hcWpEnnVgf3O9duUac7RqNHKlTK9IueQP4S6yvPVr3 nvrr+SdXhIKSW5bChwnvDsyTOeMBAw3bLE6P2tt2C6q3FDWHlB8IQOrg3S8K55nU4YBp+v qkWCbTqBBTJ65f+8SkGEepHMahcDOOU= Received: from [192.168.168.200] (161-097-205-025.v4.mynextlight.net [161.97.205.25]) by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id cdc91128 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <9front@9front.org>; Wed, 29 Mar 2023 15:37:45 -0500 (CDT) Message-ID: <21fea124-b5a9-db54-561d-f0dff24a084e@posixcafe.org> Date: Wed, 29 Mar 2023 14:31:16 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Content-Language: en-US To: 9front@9front.org References: <7DE8FD327C993A1A92A480A88E8B9D4E@smtp.pobox.com> From: Jacob Moody In-Reply-To: <7DE8FD327C993A1A92A480A88E8B9D4E@smtp.pobox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: social core YAML app reduce/map interface Subject: Re: [9front] srv(3) clone and srvid Reply-To: 9front@9front.org Precedence: bulk On 3/29/23 14:15, unobe@cpan.org wrote: > 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. #s20 and $s/20 are different things. The first is an attach argument, the second is access the sub directory 20. > >> 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% /fd/0:2: < can't open: f: 'f' not found > cpu% lc /srv > 36/ cons mntexport slashmnt > acme.glenn.3372 cs pin-glenn slashn > acme.glenn.908 dns plumb.glenn.495 > boot factotum rio.glenn.504 > clone hjfs.cmd rio.glenn.836 > cpu% bind -c '#s36' /srv > cpu% lc /srv > 36/ cons mntexport slashmnt > acme.glenn.3372 cs pin-glenn slashn > acme.glenn.908 dns plumb.glenn.495 > boot factotum rio.glenn.504 > clone hjfs.cmd rio.glenn.836 > cpu% bind -c '#s'/36 /srv > cpu% lc /srv > clone > > When the window is closed, then 36/ finally is cleaned up. > > This seems like an rc bug that is leaking the file descriptor.