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=iSqF8fFa; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id D446F5A0271 for ; Wed, 10 Dec 2025 13:05:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1765368315; 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=qcXxVL8wHGCp2+cj2/23bK6/rGo1J5IfeLCg5fb1isI=; b=iSqF8fFaZseWMp59z7Zo+nPD0TyB7HnUUFZjhQGz6ENMsUbdy5WJm/sd5II+Fr01CcD6fx VbVSVIPj0w/gyDIUym0lFNJ93PiuF5O8Bl2rxTwkfTpoPsQ0cLjMcSlN5S363wUG8PZIUw wlMAyCZuCktYKpHoDqSxbRl4vyhKWiE= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-549-PZsMd57aMdOgN-7BxGTkrw-1; Wed, 10 Dec 2025 07:05:14 -0500 X-MC-Unique: PZsMd57aMdOgN-7BxGTkrw-1 X-Mimecast-MFC-AGG-ID: PZsMd57aMdOgN-7BxGTkrw_1765368313 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-42e2e2ee360so4582867f8f.0 for ; Wed, 10 Dec 2025 04:05:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765368313; x=1765973113; h=content-transfer-encoding:in-reply-to:from:cc:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qcXxVL8wHGCp2+cj2/23bK6/rGo1J5IfeLCg5fb1isI=; b=Vvt5x1BOKj2wa3bq18jP0bCv3+dZHWgqzroqsi08Hsgys5/B5irlPY1oCbMq5FZKbW iqp9QAroTkVMkw3cJ1tytiWhz+wX3q/13ijLpqJN50zhCHU6uDhWUIgCj56nCtysV+l2 vpbsmpBdOvTsEawriV3euFCDdDOZYt/XUxp/AMw27lF4vHA0ebZ6hYBiUpTK9JoBRb5u EI70o/PNSrIRilBE6sWo+sOcJ/6LENPBc18K5DAGtkUsqhGeLy0AtXqV4SaYMCA8N96n H+UpIGRv1sZI1y4S7v29ynOOBV6tNHongZ6TFB8LYleQcjl44lQyVeXlor22RuZn+ViO BHOg== X-Gm-Message-State: AOJu0YyegDAq9Rm0TFjYTteJ9oxN9zCUbHDoPMs8fzMjXsQzlzCk8EUC gvn7iAnB4jTyfF0aFxzVvc59wUtPbQ4eqpSFPDoMnHEpu6rtlsJxkU+ck6gOSCWdVIvkC14mJeL zVmYlxxSapIsX7d9g5X5iTMJbAFk3bo53C2j/9zVO9sHzPmi1aXvm5w== X-Gm-Gg: AY/fxX7E91IifndQb1A2ddVv5GKN1syEhS3i3tevbN14GpJ6Anr3eYu4Js2JTLgtxwx xKahIn6xPKdLJf7Z4keMaNDt+1Z3jRLyqhHckjQ2q47XSM330s9fTwBp648SWxbowzmErEIZa8z oB9WU12hEI58uaTNCl3Y8oDXUvHPmSxHdRuROnzwzBGMOl/ZsZIS08UWwDECVhA0kg4oTJ3Gr/O NdKot9b3C5kNRnToo2GZ5AUQvQu/DwG4f+iFZsd5poFh77L8VvrtJ147Farx6RX1+nUUE27/bae FUvig1hzNUyK4gO46tEF4IAHnbRSdyIYu2TAUXXR06fJtJ0OxHv4urGwLF0Yn86X/jH74a6whjT JbqbCPvhAYLB90zo= X-Received: by 2002:a05:6000:26ca:b0:42b:32c3:392a with SMTP id ffacd0b85a97d-42fa39d49c7mr2498646f8f.20.1765368312658; Wed, 10 Dec 2025 04:05:12 -0800 (PST) X-Google-Smtp-Source: AGHT+IHkWOChTiw2HZ64yAy3KWrodIHjDaYcA/6yMfwmeRg9VDhHxdbdC8JERvHpOTVVr02Gqs/4lw== X-Received: by 2002:a05:6000:26ca:b0:42b:32c3:392a with SMTP id ffacd0b85a97d-42fa39d49c7mr2498585f8f.20.1765368312045; Wed, 10 Dec 2025 04:05:12 -0800 (PST) Received: from [192.168.188.22] ([80.243.52.136]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-42f7cbfeae9sm37702257f8f.13.2025.12.10.04.05.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Dec 2025 04:05:11 -0800 (PST) Message-ID: <3b553775-1ee8-4b87-8b9c-ff0dec281576@redhat.com> Date: Wed, 10 Dec 2025 13:05:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] pasta: Clean up waiting pasta child on failures To: David Gibson , Stefano Brivio References: <20251210051552.1157177-1-david@gibson.dropbear.id.au> <20251210051552.1157177-3-david@gibson.dropbear.id.au> From: Paul Holzinger In-Reply-To: <20251210051552.1157177-3-david@gibson.dropbear.id.au> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: GAzzUbFDNMtqbAtVAoNBI5xce0Irjj6e_FXWQdCM7DQ_1765368313 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: BVCBHX43V7JO3SCLYRHXHDJCQ44CENBA X-Message-ID-Hash: BVCBHX43V7JO3SCLYRHXHDJCQ44CENBA X-MailFrom: pholzing@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 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: On 10/12/2025 06:15, David Gibson wrote: > When pasta is invoked with a command rather than an existing namespace to > attach to, it spawns a child process to run a shell or other command. We > create that process during conf(), since we need the namespace to exist for > much of our setup. However, we don't want the specified command to run > until the pasta network interface is ready for use. Therefore, > pasta_spawn_cmd() executing in the child waits before exec()ing. main() > signals the child to continue with SIGUSR1 shortly before entering the > main forwarding loop. > > This has the downside that if we exit due to any kind of failure between > conf() and the SIGUSR1, the child process will be around waiting > indefinitely. The user must manually clean this up. > > Make this cleaner, by having passt_exit() terminate the child, when called > during this window. > > Signed-off-by: David Gibson > --- > passt.c | 1 + > pasta.c | 2 ++ > pasta.h | 1 + > util.c | 5 +++++ > 4 files changed, 9 insertions(+) > > diff --git a/passt.c b/passt.c > index cf38822f..955c7091 100644 > --- a/passt.c > +++ b/passt.c > @@ -431,6 +431,7 @@ int main(int argc, char **argv) > if (pasta_child_pid) { > kill(pasta_child_pid, SIGUSR1); > log_stderr = false; > + pasta_child_signalled = true; > } > > isolate_postfork(&c); > diff --git a/pasta.c b/pasta.c > index 5c693de1..8ac4511f 100644 > --- a/pasta.c > +++ b/pasta.c > @@ -54,6 +54,8 @@ > > /* PID of child, in case we created a namespace */ > int pasta_child_pid; > +/* Has the child been signalled to start a shell or command */ > +bool pasta_child_signalled; > > /** > * pasta_child_handler() - Exit once shell exits (if we started it), reap clones > diff --git a/pasta.h b/pasta.h > index 4b063d13..55028c74 100644 > --- a/pasta.h > +++ b/pasta.h > @@ -7,6 +7,7 @@ > #define PASTA_H > > extern int pasta_child_pid; > +extern bool pasta_child_signalled; > > void pasta_open_ns(struct ctx *c, const char *netns); > void pasta_start_ns(struct ctx *c, uid_t uid, gid_t gid, > diff --git a/util.c b/util.c > index e266c396..4744f09e 100644 > --- a/util.c > +++ b/util.c > @@ -35,6 +35,7 @@ > #include "log.h" > #include "pcap.h" > #include "epoll_ctl.h" > +#include "pasta.h" > #ifdef HAS_GETRANDOM > #include > #endif > @@ -1235,6 +1236,10 @@ void abort_with_msg(const char *fmt, ...) > */ > void passt_exit(int status) > { > + /* If we're starting our own namespace, don't leave it in limbo */ > + if (pasta_child_pid && !pasta_child_signalled) > + kill(pasta_child_pid, SIGTERM); Any reason not to use SIGKILL? Then there is no doubt if it might be ignored or not. Another thing I assume the goal here is to only kill the process if we didn't exec yet. I wonder how much value there is to have the child process outlive pasta. I feel like using something like PR_SET_PDEATHSIG might be a safer option in case pasta crashes without going through passt_exit. And if you don't want to propagate that into the user command we could unset it right again before the exec as well. > + > /* Make sure we don't leave the pcap file truncated */ > if (pcap_fd != -1 && fsync(pcap_fd)) > warn_perror("Failed to flush pcap file, it might be truncated"); -- Paul Holzinger