From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTP id D5D715A0082 for ; Tue, 14 Feb 2023 09:01:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676361702; 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=jcRqWTJBDAVLyqNKAc09hsh/cCyBGTOUaL83d2CTgfE=; b=Lj91zdObcI/fIwYKSCQco6VhEQtnqv1CCXggBCTVwfsoZUrHas9B9cFZjY9/ewO2gVO6bw Q5MK2flOvrcv4YhDdq7IbT4VNAP4OqBmOxCQF71tmte9ipkH2NjTOzqSjBn3RPVeaY7ByJ wP7rrx3ybtrXItuCMgSp48/72/EmlXc= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-63-8TZppK6LPwGRiqJ60dI5Ag-1; Tue, 14 Feb 2023 03:01:41 -0500 X-MC-Unique: 8TZppK6LPwGRiqJ60dI5Ag-1 Received: by mail-ej1-f69.google.com with SMTP id ga33-20020a1709070c2100b008b11f37b9c6so2490601ejc.14 for ; Tue, 14 Feb 2023 00:01:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jcRqWTJBDAVLyqNKAc09hsh/cCyBGTOUaL83d2CTgfE=; b=VEtyFAxvECoxPGZ1df26xCtJ6bpg6TonDU6I9L1YtfhoauqF5bf8Z5KtKC9CVbMvuq cpVigBbup50HSfIrPTkihhnB6dDIVwNEo9LxCgccmZwA6d+235KChr2jZXNW/POZqC8l OyXeLxB5dHs8Tkf9Hafi/caA7LLM+qf1sSmcMvNSUzVzKPX+FK+cThvayhyPUlcdzA++ oib36jRX1rXCltMmqpZqqjiZmUeRQBmcF3FKKqJMA//9l2xRjlZ9lPNL2tWjp4RkeFDX Y6FYMoffrJ94qID4XdRwUyckCqS1YQB7537l2Tl+ltlokcGeSB3PNPA6iUMQ9VTxqlvz qF6g== X-Gm-Message-State: AO0yUKX11bHtjuT1YrUeRH5NlCPoiiqHG3GSHZwCuEusf6D8iAIka+Bf OrCGfnag0hSXqXyfsbgpkfvcHHSlybCrnrg5/zJSakY2BJQ0VA5VHwC2y+BGucWZWPNsXu9eoYS 7Tlz3bARcIXwQ X-Received: by 2002:a50:c308:0:b0:4ab:4c5e:8828 with SMTP id a8-20020a50c308000000b004ab4c5e8828mr1447022edb.37.1676361700453; Tue, 14 Feb 2023 00:01:40 -0800 (PST) X-Google-Smtp-Source: AK7set/pChvtplHDCvfbtXuTKX8qCextdAwyKuiysWBRCzFpy/kRHIo/WUed0eFDkLMhAuQT/1azmA== X-Received: by 2002:a50:c308:0:b0:4ab:4c5e:8828 with SMTP id a8-20020a50c308000000b004ab4c5e8828mr1447001edb.37.1676361700247; Tue, 14 Feb 2023 00:01:40 -0800 (PST) Received: from [10.43.2.39] (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id f8-20020a50d548000000b004ab33d52d03sm6680156edj.22.2023.02.14.00.01.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Feb 2023 00:01:39 -0800 (PST) Message-ID: Date: Tue, 14 Feb 2023 09:01:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [libvirt PATCH] qemu: allow passt to self-daemonize To: Laine Stump , libvir-list@redhat.com References: <20230208231310.1728051-1-laine@redhat.com> From: =?UTF-8?B?TWljaGFsIFByw612b3puw61r?= In-Reply-To: <20230208231310.1728051-1-laine@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-MailFrom: mprivozn@redhat.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: IXTG3AS43COXMLNVOVW35DT4E6Y6TWZP X-Message-ID-Hash: IXTG3AS43COXMLNVOVW35DT4E6Y6TWZP X-Mailman-Approved-At: Tue, 14 Feb 2023 10:52:01 +0100 CC: passt-dev@passt.top, =?UTF-8?Q?J=c3=a1n_Tomko?= X-Mailman-Version: 3.3.3 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 2/9/23 00:13, Laine Stump wrote: > I initially had the passt process being started in an identical > fashion to the slirp-helper - libvirt was daemonizing the new process > and recording its pid in a pidfile. The problem with this is that, > since it is daemonized immediately, any startup error in passt happens > after the daemonization, and thus isn't seen by libvirt - libvirt > believes that the process has started successfully and continues on > its merry way. The result was that sometimes a guest would be started, > but there would be no passt process for qemu to use for network > traffic. > > Instead, we should be starting passt in the same manner we start > dnsmasq - we just exec it as normal (along with a request that passt > create the pidfile, which is just another option on the passt > commandline) and wait for the child process to exit; passt then has a > chance to parse its commandline and complete all the setup prior to > daemonizing itself; if it encounters an error and exits with a non-0 > code, libvirt will see the code and know about the failure. We can > then grab the output from stderr, log that so the "user" has some idea > of what went wrong, and then fail the guest startup. > > Signed-off-by: Laine Stump > --- > src/qemu/qemu_passt.c | 9 ++++----- > 1 file changed, 4 insertions(+), 5 deletions(-) OOOPS, somehow I've accidentally merged this. Let me post follow up patches. > > diff --git a/src/qemu/qemu_passt.c b/src/qemu/qemu_passt.c > index 0f09bf3db8..f640a69c00 100644 > --- a/src/qemu/qemu_passt.c > +++ b/src/qemu/qemu_passt.c > @@ -141,24 +141,23 @@ qemuPasstStart(virDomainObj *vm, > g_autofree char *passtSocketName = qemuPasstCreateSocketPath(vm, net); > g_autoptr(virCommand) cmd = NULL; > g_autofree char *pidfile = qemuPasstCreatePidFilename(vm, net); > + g_autofree char *errbuf = NULL; > char macaddr[VIR_MAC_STRING_BUFLEN]; > size_t i; > pid_t pid = (pid_t) -1; > int exitstatus = 0; > int cmdret = 0; > - VIR_AUTOCLOSE errfd = -1; > > cmd = virCommandNew(PASST); > > virCommandClearCaps(cmd); > - virCommandSetPidFile(cmd, pidfile); > - virCommandSetErrorFD(cmd, &errfd); > - virCommandDaemonize(cmd); > + virCommandSetErrorBuffer(cmd, &errbuf); > > virCommandAddArgList(cmd, > "--one-off", BTW: we definitely need something better than this. IF, something goes wrong after we've executed passt but before we execute QEMU, then passt just hangs there. This is because passt clone()-s itself (i.e. creates a child process), but QEMU that would connect to the socket never comes around. Thus, the child process never sees the EOF on the socket and just hangs in there thinking there will be somebody connecting, soon. I thought this could be solved by just killing the whole process group, but the child process calls setsid(), which creates its own process group. I've managed to work around this by passing --foreground, but I'm unclear about the consequences. Though, it looks like it's still dropping caps, creating its own namespaces, etc. So this may actually be the way to go. But in general, we may need to make our pid handling better. I remember Jano mentioned some problems with virtiofsd which also fork()-s. Michal