From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: passt.top; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20251104 header.b=QTqnH3dH; dkim-atps=neutral Received: from mail-yx1-xb134.google.com (mail-yx1-xb134.google.com [IPv6:2607:f8b0:4864:20::b134]) by passt.top (Postfix) with ESMTPS id 3F0B55A0262 for ; Tue, 02 Jun 2026 20:51:35 +0200 (CEST) Received: by mail-yx1-xb134.google.com with SMTP id 956f58d0204a3-66061993294so3512008d50.3 for ; Tue, 02 Jun 2026 11:51:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780426294; cv=none; d=google.com; s=arc-20240605; b=R9zz4/fYxzkHmeroMO5OgqvW5J+gb63HGMaejJepvvhi04gd62Hs7Uu6DzoPgHznP8 d384gxiCWnZZC9A0KPD7jlQZYrnBt5kQlJT3yomsMI1a0fm9iacp0nw4Jy6esyawSAsL orVEy3p9Dt3KOATi7g6NuuV93fBXxWbOoK7fiFOt9a0JRbo7lo+3HGo383/okf1pEl7w ofIoXr2I9uABg4LM3g6Aum71v1PA5FpbThk5276/vheQQhFd58Fh2/Sk3cpUsBvmT/Fu mckTO5r05NBCuXYMFPpONKYkDl3VL+Dx8fUCnlEIDH5fVSYFC/jC3epcqmd7VF+2/HX0 Uy9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=ZNhYUqPa0jFm3RQLmb5xVDseo0/Nu3+J4EseUO9X4HU=; fh=LixnwuzT+5G9Nq3t1Tdkvl+TM3eOhuGYMY9jbNbitzc=; b=bR5TBz6F7uv/omxabzkX26uLq/OndiC3tEB6wGDYObqValc35WfP7wcHq4W8JWwK1d MCCtcbMharh5Un8BP4NXBQr3KanzOGJ1oZ5YmK7nsnnqdT6IMoUHunzraWcNYXSIfWVR MoplLbCslBEMKzr8m+on04MQKmvuFHSNBEVhypvcR1tvKxQP8nH8lnFNjwipIp8W+nCP uN0+tAbDJw/ESbzp5ceerCh+2v3+Q6wvxZvL/FQAt7tlDW83ddm+cXGharpXE+rF9n6N 8fFKXtSPPzlfVfFKwGrv9U1AYFK208v4dSuepZTzculUSSb+aelrNz4WdaSGWbGEROIK NwyQ==; darn=passt.top ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780426294; x=1781031094; darn=passt.top; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZNhYUqPa0jFm3RQLmb5xVDseo0/Nu3+J4EseUO9X4HU=; b=QTqnH3dH2Key3/E+3P1sBXgt3EJPNGgtcLOabW4O/Kyl4A3SdmwYzSuEOx9WvCfb+i FkHAqjxbzQkWrNKkBDbs/GVmyZQMvCOdGt4mWQV3vIrHjrUBb2w8xfkJ6AzL8r5dS0/T +mdNFoxBecFIvZ/TZx1PBD02JDkjvwObBGHa9weWn11tSfId4dWL2tn21FJ1AqkhxbE3 eKpXnhl5ehzuL6rQKzERJ630IoVvmej2EQs/iDjAxZssacLAlInhMA6LOL+7yDCeT+Bt P+Ph0kaciyNdA9UEqkfbXeeK7D2hQdk4clBCzkZoZRwgDeQVrT0j37D+yj6iDco4C6g1 /NMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780426294; x=1781031094; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ZNhYUqPa0jFm3RQLmb5xVDseo0/Nu3+J4EseUO9X4HU=; b=RG8vvvoEUMnpMIwSToZESRt50OUOra1LJDntgwdL6+bsdQufoqZJ59qT3MhsTl3/U3 JUxaOevtjhcCFcGw5vI8bu3laxmNaBSmEaxLdzMOns3aXlFWs0/nkwwesCr35c603AjN oLW8jsNIUnVZm/qZrY7ixAvNB73aByITnJsElJUrtG0ZKqZcusZXumYbK2F+c6FojuzO z0+bcaIp3RIa5AwuoChlOD7qrnTA+Yry/ZXwR9y8TMnhD6miIA5H87oxNCtZYGl6b8mH VNfvng2TRZVGLdn5X9YapiJJWE/2v68SRo/a1CGKfVQR8/tV1OABL3s52ceWIsV0E7h3 Ocbg== X-Gm-Message-State: AOJu0YzHIPKTM/c00VTIQWcChtEJgG0lLadyyGvFv64Kix26n0jyOmpj F+/OfdqzOvsItKJNbyA7T6x5OK+wPe8IcDAkEc1H/bvjR/DXOP5D/1Ph3bRSsGdYZq8LJ6MWbc8 HjTKPUaHT/hI/M7YHZbmD2Pelhv2R8T0= X-Gm-Gg: Acq92OEziYZ+uRNMLU9H7Ib/erfTVchdyr8wSEgtW0o7WvEKm1XxfEn9tj6Q33QMvSI naJ5htcM7DuvFfxQnrt8qAPemjZ+pSuXTA6pDPJy+x7AyjP5KKuoThl+tELJltbKIth2HFMGFqJ Exh6MWdD2VbRjRWk+fMspzzOixOnvtBVi46A+xFwZF/LJeG6VOWYQA5SvfEGgZak/p3tiwCILVj Z9qN3O/8Om0L+4UCm5MwGGTJfunDdE37Uf6fF1EUZ1itKCLeXIYIbKQhEIUtirsXm30tIySCr/E y/EAj/CGt4zzEtZhyG8k4O1ngHLSfT6zIbgcu4DMqWSt/J7ARGpL X-Received: by 2002:a53:b3cd:0:b0:660:62e5:9300 with SMTP id 956f58d0204a3-660dc59abdamr35307d50.48.1780426293636; Tue, 02 Jun 2026 11:51:33 -0700 (PDT) MIME-Version: 1.0 References: <20260527213924.2586bca5@elisabeth> In-Reply-To: <20260527213924.2586bca5@elisabeth> From: Lisanna Dettwyler Date: Tue, 2 Jun 2026 14:51:21 -0400 X-Gm-Features: AVHnY4IDH0bskpeiH_iq6TlG6LEyLkcxex-jApTAFX7eNUCDAs2Yo_K5i9i_zIo Message-ID: Subject: Re: Startup fd to avoid busywaits To: Stefano Brivio Content-Type: multipart/alternative; boundary="000000000000c7f1b9065349ccc9" X-MailFrom: lisanna.dettwyler@gmail.com X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation Message-ID-Hash: Q532KCBGWIV243HR4Q5OFDSEY2D3MGEJ X-Message-ID-Hash: Q532KCBGWIV243HR4Q5OFDSEY2D3MGEJ X-Mailman-Approved-At: Wed, 03 Jun 2026 00:45:00 +0200 CC: passt-dev@passt.top, David Gibson X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000c7f1b9065349ccc9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, Thanks for the detailed replies! It looks like allowing it to daemonize and waiting on the parent works just fine. The comments in the code I linked are from a different developer associated with a fork of Nix, I think for our purposes allowing it to exit on its own is perfectly fine, but I'll check on this. As far as the namespace joining goes, pasta doesn't have permissions to join the namespaces if provided verbatim without the redirection hack, but let me get back to you on this also. Thanks, Lisanna On Wed, May 27, 2026 at 3:39=E2=80=AFPM Stefano Brivio = wrote: > Hi Lisanna, > > On Wed, 27 May 2026 13:08:01 -0400 > Lisanna Dettwyler wrote: > > > Hello! I would like to propose a patch that allows the invoker to pass = a > > "ready fd" on startup that gets written to once the setup has been > > completed, similar to slirp4netns's `--ready-fd` flag. Currently we hav= e > to > > poll the interface in a loop to wait for setup to be completed, and it > > would be much better if we could instead block on fd activity. > > As I was implementing the first prototype of pasta, I spotted this in > slirp4netns and I was rather surprised because... > > > Just wanted to check if such a contribution would be welcome before > putting > > in the work of authoring it, or if there's already a better way to wait > for > > the interface to come up. > > ...traditionally, well-behaved UNIX daemons fork to background when > they're ready, and that's what pasta does. > > This fits quite naturally with typical UNIX-like tools and interfaces: > if you want to start pasta (as a daemon) from a script, just do: > > [whatever comes before] > pasta > [whatever comes after, now that pasta is ready] > > Instead of opening a file descriptor, starting a subshell, waiting for > that file descriptor, etc. > > This is how other tools generally start pasta (and passt). Podman calls > exec.Command(), for example: > > > https://github.com/containers/common/blob/a5ccdae846b629b5ceaefa6ffd5c651= 1409c3487/libnetwork/pasta/pasta_linux.go#L71 > > > This is our current implementation: > > > https://github.com/NixOS/nix/pull/15919/changes#diff-2a9176262efad1ef345d= 882b0779646e7a5aaf9ca8db33e9da7fc408594b5377R94-R125 > > Ouch, that looks rather painful. :( I read this comment, a bit above: > > // Bring up pasta, for handling FOD networking. We don't let it > daemonize > // itself for process managements reasons and kill it manually when > done. > > but it's not clear to me what "process managements reasons" might be. > Maybe we have another way to satisfy those requirements? I tried quite > hard to make it all as simple and as boring as possible. > > About this other comment: > > // FIXME ideally we want a notification when pasta exits, but we > cannot do > // this at present [...] > > ...I think ideally the easiest would be to just let pasta terminate by > itself, given that you set up namespaces externally (just like Podman > and Docker/rootlesskit do). > > But pasta can also write a PID file, and you could pidfd_open() on its > PID. I think that would be much cleaner. > > While at it, a bit below: > > // TODO these redirections are crimes. pasta closes all > non-stdio file > // descriptors very early and lacks fd arguments for the > namespaces we > // want it to join. we cannot have pasta join the namespaces > via pids; > // doing so requires capabilities which pasta *also* drops > very early. > > ...actually, pasta explicitly supports joining namespaces via PIDs, I'm > not entirely sure what would prevent it in Nix. Would there be some > capability we need to drop a bit later? > > On that topic, you might be interested in: > > https://bugs.passt.top/show_bug.cgi?id=3D204 > > and, perhaps more importantly, in these points coming from the NixPak / > bubblewrap usage: > > https://bugs.passt.top/show_bug.cgi?id=3D204#c3 > > https://archives.passt.top/passt-user/671252c8-88f6-45b7-b719-b82786e84bb= 7@gnedt.at/ > > I'm not opposed to a --ready-fd (and a --keep-fds) option if that > solves issues for you, of course, but I'd say let's make sure we're not > duplicating existing (maybe more robust?) mechanisms first. > > -- > Stefano > > --000000000000c7f1b9065349ccc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Thanks for the detailed replies= ! It looks like allowing it to daemonize and waiting on the parent works ju= st fine. The comments in the code I linked are from a different developer a= ssociated with a fork of Nix, I think for our purposes allowing it to exit = on its own is perfectly fine, but I'll check on this.

As far as the namespace joining goes, pasta doesn't have permis= sions to join the namespaces if provided verbatim without the redirection h= ack, but let me get back to you on this also.=C2=A0

Thanks,
Lisanna

On Wed, May 27, 2026= at 3:39=E2=80=AFPM Stefano Brivio <sbrivio@redhat.com> wrote:
Hi Lisanna,

On Wed, 27 May 2026 13:08:01 -0400
Lisanna Dettwyler <lisanna.dettwyler@gmail.com> wrote:

> Hello! I would like to propose a patch that allows the invoker to pass= a
> "ready fd" on startup that gets written to once the setup ha= s been
> completed, similar to slirp4netns's `--ready-fd` flag. Currently w= e have to
> poll the interface in a loop to wait for setup to be completed, and it=
> would be much better if we could instead block on fd activity.

As I was implementing the first prototype of pasta, I spotted this in
slirp4netns and I was rather surprised because...

> Just wanted to check if such a contribution would be welcome before pu= tting
> in the work of authoring it, or if there's already a better way to= wait for
> the interface to come up.

...traditionally, well-behaved UNIX daemons fork to background when
they're ready, and that's what pasta does.

This fits quite naturally with typical UNIX-like tools and interfaces:
if you want to start pasta (as a daemon) from a script, just do:

=C2=A0 [whatever comes before]
=C2=A0 pasta
=C2=A0 [whatever comes after, now that pasta is ready]

Instead of opening a file descriptor, starting a subshell, waiting for
that file descriptor, etc.

This is how other tools generally start pasta (and passt). Podman calls
exec.Command(), for example:

=C2=A0 https://github.com/containers/common/blob/a5ccdae8= 46b629b5ceaefa6ffd5c6511409c3487/libnetwork/pasta/pasta_linux.go#L71
> This is our current implementation:
> https://github.com/NixOS/nix/pull/15919/chang= es#diff-2a9176262efad1ef345d882b0779646e7a5aaf9ca8db33e9da7fc408594b5377R94= -R125

Ouch, that looks rather painful. :( I read this comment, a bit above:

=C2=A0 =C2=A0 // Bring up pasta, for handling FOD networking. We don't = let it daemonize
=C2=A0 =C2=A0 // itself for process managements reasons and kill it manuall= y when done.

but it's not clear to me what "process managements reasons" m= ight be.
Maybe we have another way to satisfy those requirements? I tried quite
hard to make it all as simple and as boring as possible.

About this other comment:

=C2=A0 =C2=A0 // FIXME ideally we want a notification when pasta exits, but= we cannot do
=C2=A0 =C2=A0 // this at present [...]

...I think ideally the easiest would be to just let pasta terminate by
itself, given that you set up namespaces externally (just like Podman
and Docker/rootlesskit do).

But pasta can also write a PID file, and you could pidfd_open() on its
PID. I think that would be much cleaner.

While at it, a bit below:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // TODO these redirections are cr= imes. pasta closes all non-stdio file
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // descriptors very early and lac= ks fd arguments for the namespaces we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // want it to join. we cannot hav= e pasta join the namespaces via pids;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // doing so requires capabilities= which pasta *also* drops very early.

...actually, pasta explicitly supports joining namespaces via PIDs, I'm=
not entirely sure what would prevent it in Nix. Would there be some
capability we need to drop a bit later?

On that topic, you might be interested in:

=C2=A0 https://bugs.passt.top/show_bug.cgi?id=3D204<= br>
and, perhaps more importantly, in these points coming from the NixPak /
bubblewrap usage:

=C2=A0 https://bugs.passt.top/show_bug.cgi?id=3D204#c= 3
=C2=A0 https://a= rchives.passt.top/passt-user/671252c8-88f6-45b7-b719-b82786e84bb7@gnedt.at/=

I'm not opposed to a --ready-fd (and a --keep-fds) option if that
solves issues for you, of course, but I'd say let's make sure we= 9;re not
duplicating existing (maybe more robust?) mechanisms first.

--
Stefano

--000000000000c7f1b9065349ccc9--