From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=VKjx2RVb; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 032BF5A0262 for ; Wed, 27 May 2026 21:39:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779910770; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gVqisGS1jHpGWKG48UpIZBVnhiANhj+zyrkuIs9H/YQ=; b=VKjx2RVbiVOUmhyuEmstsMYwLrYK6ih3IrFdKuneBDAlwLDwrAoK7KLjc+DkXnx7F9m+26 +4gH+zbOLh9nKUJPvbXpL3lS16TreXOeT7EIwRcCHJ0KydiXF2QMLnn3jbpXCHGXHq66Tv bm4HwhYLlMGaQj15FRlTRy5Cq9amKcY= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-314-pKGqpzvmNtCUCrK2L1XN6w-1; Wed, 27 May 2026 15:39:28 -0400 X-MC-Unique: pKGqpzvmNtCUCrK2L1XN6w-1 X-Mimecast-MFC-AGG-ID: pKGqpzvmNtCUCrK2L1XN6w_1779910768 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-48e79219704so83251835e9.1 for ; Wed, 27 May 2026 12:39:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779910768; x=1780515568; h=date:content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=gVqisGS1jHpGWKG48UpIZBVnhiANhj+zyrkuIs9H/YQ=; b=SOMcclq6XrrAJiS+71DYdjW5VuArpT+DNe0XOYbsmXb0S85sVboBOylVrHk60E5GCx 5tnajPrLNbXQaJOYPbfHmr4Pb5esYvkB5hc3YyLjEM9qNy/16yKjpk5NYGeG5J7X/I5e 0gI619SYMUPXuyStFEaz/mRPiteC4B/vUCH+AqVX5WbgaSDyQZcmnnKBvWItMQyRyifk gqXlOLrVWK5Nzehd6X1JlwuC2j5v3v+Fo9wm6y4G+UdH+9FvQlRdtytwml/KfFgeQnK3 M4GF/JV/o/BBD9kRql13eAydj+G3wGyte6bV3kb0V9EJa2nIjApXEG7mVoSII4K6A5Tw DliA== X-Gm-Message-State: AOJu0YxvKCEV/iTmcn6Z1Jp7KuaMdh1yP4jiDE8PDOYtMFtFYmO2Dgl/ IU39iN8YiIhHWRY0FDnKUPYmr8UVeoHXEO4PxftOc/RKxHS6otSpDuXiNKfMX122uT7ICKDq4Ni Q9ldBSJKsSHGprndzUbfLc+vm+fPyhDqgXyZDanZJ9Bc35AOEFKrB/A== X-Gm-Gg: Acq92OHxNHuvH2AVZWe5xeo0e5hkSlOfmEBrptQPdZPMv+aN9vhnYU1YHov+tzlc8oK UTIhPJR5VE2flJvKngysYrVfbn/t8+aLk4YocEI9gxL1zWAvarA5I3Ggu58GMqTYMQHBKYC9+8e SHTpDw8sv4fkqfYDr8k1E1unnUXyyqcC6WCE170Zzw/xndxQnz+0Ok9kI4Qo4ZDss4HQ16LcjdI LTDe9Y8eeDw8OHh8mlGOLVQBYmtgBMeWbyYVD/64mgQ2mTgg1c9CgTOVM9x0JN7PGrdoZBSYkCS pZFHGctg/o3eStXa60JPZpH9Xes6RqgyFC2mHdA0Zwmhu1U/s6s+KkvwCREWayy2lyQjzkNEave LoBZMepBv6r3zunqlvsnVu41zGc8qzk3IVbc8VYJnmVqqjvXnHBqdzGTBgyU2 X-Received: by 2002:a05:600c:674a:b0:490:5057:f5f7 with SMTP id 5b1f17b1804b1-49050580a91mr346110705e9.11.1779910767441; Wed, 27 May 2026 12:39:27 -0700 (PDT) X-Received: by 2002:a05:600c:674a:b0:490:5057:f5f7 with SMTP id 5b1f17b1804b1-49050580a91mr346110285e9.11.1779910766821; Wed, 27 May 2026 12:39:26 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45edb549addsm7945147f8f.5.2026.05.27.12.39.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 May 2026 12:39:25 -0700 (PDT) From: Stefano Brivio To: Lisanna Dettwyler Subject: Re: Startup fd to avoid busywaits Message-ID: <20260527213924.2586bca5@elisabeth> In-Reply-To: References: Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Wed, 27 May 2026 21:39:25 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: kmLOWAMy2gdNvlCzUvcuD7WcVVFGYpDW5EGjmXBXUDI_1779910768 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: GVWTO7LK2XUL2D6WJM5Y6WPARDQOGB5T X-Message-ID-Hash: GVWTO7LK2XUL2D6WJM5Y6WPARDQOGB5T X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header 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: 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 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 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/a5ccdae846b629b5ceaefa6ffd5c6511409c3487/libnetwork/pasta/pasta_linux.go#L71 > This is our current implementation: > https://github.com/NixOS/nix/pull/15919/changes#diff-2a9176262efad1ef345d882b0779646e7a5aaf9ca8db33e9da7fc408594b5377R94-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=204 and, perhaps more importantly, in these points coming from the NixPak / bubblewrap usage: https://bugs.passt.top/show_bug.cgi?id=204#c3 https://archives.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're not duplicating existing (maybe more robust?) mechanisms first. -- Stefano