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=bJLGrqnp; 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 6D5AB5A0625 for ; Thu, 11 Dec 2025 14:49:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1765460995; 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=qwiDx44QYmQnXe00nBpWIPWO2uDbYPSbBlNCT5AVI9I=; b=bJLGrqnpGLuSFWEHwMWjotS6Ubf8YjCnl2tI2Llf6NFCmotUv7P0yKKplwZ/oZOkKFB0YU ln0IkgFbgzvyA2g1gKZPvFyEzCIt6rhjsRBZqMyz/ir4T6AI8Rbf65waYsTPOnkKs84WUE L+4tsYSW2NnhRzqDcW3XmZMZlCk6usE= 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-484-W1CUTbElO2GlfqDeBOsm6A-1; Thu, 11 Dec 2025 08:49:54 -0500 X-MC-Unique: W1CUTbElO2GlfqDeBOsm6A-1 X-Mimecast-MFC-AGG-ID: W1CUTbElO2GlfqDeBOsm6A_1765460993 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-477a0ddd1d4so802315e9.0 for ; Thu, 11 Dec 2025 05:49:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765460993; x=1766065793; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc: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=qwiDx44QYmQnXe00nBpWIPWO2uDbYPSbBlNCT5AVI9I=; b=qx3qWATYH+w8mrvn/xgRo4of0xxtypFJmMXHUdqrvDekvIDwL8glBZWQcyA6IDJJQM c2Ix4BJ1plyXTyWEbCcsI+l6WtbPQFRtGIE7qISI73hGGCCAMNIktUJ1G8MT2zwFP2Z4 KJve0Ymvm6QLarxy48Pl99jM13Ur71UyAWzErKHvAm6dfdAUh25suUlTfpgd3pgEXXm3 p3Z1XOf6rjgHRrCGLRTEiveyk5VwfJdb89bAIXiC4Mpbf28pCtarvb85HtS6eykAz6dC S/LAddElPVPRO5gSXdnvamTtcTOU8RNxSVK5gkNKc+iK1Xgz4igcmAD2GluUTlWtwg1q ZTbg== X-Forwarded-Encrypted: i=1; AJvYcCXWTPNZX4r9uI8pP8XXKNCFHhNZoQKmqRFq0ctBHY518wV8TQuIm5cR9UsgZV2kvdgwytEXqg7/Nd8=@passt.top X-Gm-Message-State: AOJu0YxfaDx6xA1I2a4J3tD8ZBP4mCtd2Y65AKjEyx85//RO0IW0ADsZ oFo+BMwWB3zM67KB0kq51pqrXwBzH/aT9zNoVQde6XnAH/xfBRj/zP9ukEKhrui9Kf1+oxNCyAC cquX5f9d6KYsemJtMWGIpLDKU+GOX8IkJvXNEKNiC5YjQCx2MAUBTJA== X-Gm-Gg: AY/fxX7bWfN5CYOQLze5naaresqsvaAfU4zropq6H6etl+5DZOB3clR+d77EyyXVKSP /z6Y4I2CdQTKreHvKSHhrjvZbb2hiETT92+LJjfmisVPF59S2CByZztOWshR3uGpFc/tperm0pF z/RbjF3Lcz+4MD8eLUfIxB0ExtKjZG6uudw31zt2PNvRkccEFzO8JdYPDv360j2dgpdKRIISlBW 0aljHXOw/+i7CHqphSiJhM/0iPgBPCAn2n5Rd8EVihvrYE/H76kpUao9NoBmcFRZDxFS1uCWHNC XZPYozrSQoCI2m9BtuhUlqVT1uEqUCleHPrp+HwPExQkVhYxd0i7b9D83SiKEZdx8/zXXgseC+m LHNgqnBaB1xbtgEM= X-Received: by 2002:a05:600c:444f:b0:477:9b35:3e36 with SMTP id 5b1f17b1804b1-47a8374ddefmr60569545e9.2.1765460992668; Thu, 11 Dec 2025 05:49:52 -0800 (PST) X-Google-Smtp-Source: AGHT+IHG9DfxeTIpMyaZhZFq1q7e3CetN484tm+k4aleCb0xaEnjXnA7NBwsCXKWg1XkyCXe4bUiJQ== X-Received: by 2002:a05:600c:444f:b0:477:9b35:3e36 with SMTP id 5b1f17b1804b1-47a8374ddefmr60569285e9.2.1765460992150; Thu, 11 Dec 2025 05:49:52 -0800 (PST) Received: from [192.168.188.22] ([80.243.52.134]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47a89ef95e1sm36716235e9.9.2025.12.11.05.49.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Dec 2025 05:49:51 -0800 (PST) Message-ID: <3151ef6f-c170-4d83-b562-8785f7fb5c67@redhat.com> Date: Thu, 11 Dec 2025 14:49:50 +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 References: <20251210051552.1157177-1-david@gibson.dropbear.id.au> <20251210051552.1157177-3-david@gibson.dropbear.id.au> <3b553775-1ee8-4b87-8b9c-ff0dec281576@redhat.com> From: Paul Holzinger In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: tMKVvCF1wuoWL67MeRoN-YlX-yx7uZd10OSpZDEaM3U_1765460993 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: TJBQWXZIGN3ROAEGHJ42M2M53XT6K4LZ X-Message-ID-Hash: TJBQWXZIGN3ROAEGHJ42M2M53XT6K4LZ 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: Stefano Brivio , 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 11/12/2025 00:45, David Gibson wrote: > On Wed, Dec 10, 2025 at 01:05:10PM +0100, Paul Holzinger wrote: >> 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. > Eh, only that some log might show KILLs on the assumption that they > indicate a bad thing happening, which isn't really the case here. > >> Another thing I assume the goal here is to only kill the process if we >> didn't exec yet. > Yes, that was the goal. > >> I wonder how much value there is to have the child process >> outlive pasta. > That's a good question, and I don't have a strong opinion either way. > I leant this way based on two factors: > > - If this happens later, once the child is established, it's possible > the user could have started running something there that remains > valuable even if it loses its network > > - If pasta dies once the child has exec()ed, the symptoms are both > more obvious and easier to clean up: the shell (or whatever) is > right there, running, and can be exited in the normal way > (e.g. running to completion or ^C). Before the exec() this leaves > a process running non-obviously which has to be spotted and killed > explicitly by the user. > > (also note that if we do kill the child after exec(), we definitely > want to use SIGTERM not SIGKILL to allow it to clean up gracefully). sure, I agree though there is bit of a common issue here. The process is in a new pid namespace so it acts as pid 1. That means unless the process adds a signal handler explicitly a signal like SIGTERM will get ignored by default. When running `sleep` as pid 1 it will ignore SIGTERM and you must kill it. We see that all the time with podman containers. > >> I feel like using something like PR_SET_PDEATHSIG might be a >> safer option in case pasta crashes without going through passt_exit. > Oh, good idea. I forgot PR_SET_PDEATHSIG was a thing. > >> 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 >> -- Paul Holzinger