From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=haytok.jp Received: from outbound.mr.icloud.com (mr-2003i-snip6-11.eps.apple.com [IPv6:2a01:b747:3000:202::5b]) by passt.top (Postfix) with ESMTPS id AEFAB5A0265 for ; Tue, 27 Oct 2026 18:25:56 +0100 (CET) Received: from outbound.mr.icloud.com (unknown [127.0.0.2]) by p00-icloudmta-asmtp-us-west-2a-100-percent-7 (Postfix) with ESMTPS id 8EF5C1801A47; Tue, 27 Oct 2026 17:25:54 +0000 (UTC) X-ICL-RepId: 01a17e65-aadf-7864-ad6b-c37c38b5ba81 X-ICL-Out-Info: HUtFAUMEWwJACUgBTUQeDx5WFlZNRAJCTQhKBkMCWxxCD1YCWwZLVxQEHFYbdwNTCU0XWENdGxIWXUVbDE4fXRsXEkNNRQgPQxkQVgFYVl0FTRpcGFkPHB1LVloOWwRHFBcbXAAXG0YCBCMCXwBFAl4JVgEwFw9WTVEZShlYABwaSVheBFNWDkZ4SgpfdS9wXQBBcV4aXwdBfFVxVQJSHzZ4OwApBVgCQAtKAi1fCksEVhMdB0dVEgRACFZQVB5BBFYVbAlYBlMZVw== Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=haytok.jp; s=sig1; t=1793121955; x=1824657955; bh=mB7cpQoCXYP6QMTRGNmYOjLvUpTNzZGRIocch/K8KEw=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To:x-icloud-hme; b=iwsDs360X4SMt+nygNHt9e7bx5yClOvpif9cRAhDMpx7BJ9tUnRj/n68efUhA/bBz0wD9qAEVhj3PmjOaclPC2taPO3Se3JNXMOhiL7N/kdCUz595teV0n5xDXcs6RwxFZFE7STxD8p/gJNNuInIOTdbhDsIEy1jQ794hUvDuhYx86A0Y/Typ4yM8qyRLZiW+LX1rJoCsbOOFfTalMcn97GbjcT5lC+NXkwUGSuE+QHu4r7hAhxfx+e9htESkedztjsXQoe4nren7kPUdIEGgFrw3TPyS29Ab6cVkZGsNyiG43BvLAfSn96UOWxTlZpZbF6pqN1RZrLmHO35lQcSDA== mail-alias-created-date: 1766251435121 Received: from smtpclient.apple (unknown [17.156.200.36]) by p00-icloudmta-asmtp-us-west-2a-100-percent-7 (Postfix) with ESMTPSA id C56EC1801A45; Tue, 27 Oct 2026 17:25:53 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81.1.10\)) Subject: Re: [PATCH] Keep listening on remaining rules if one of them fails to bind From: dev@haytok.jp In-Reply-To: <20261025153025.600a4fe9@elisabeth> Date: Wed, 28 Oct 2026 02:24:40 +0900 Content-Transfer-Encoding: 7bit Message-Id: <6A292BDB-99B3-451E-B859-FAC3D2300221@haytok.jp> References: <20261018154225.56640-1-dev@haytok.jp> <20261025153025.600a4fe9@elisabeth> To: Stefano Brivio X-Mailer: Apple Mail (2.3826.700.81.1.10) X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDI3MDA2OSBTYWx0ZWRfX5FEA4lKVPGrx jAXCxgi/KmGuHZr74kp5atb/pEgpvLQwIo/uMlUm+fiNziAtxQjRhJdfOlvdvNjXcGh40Zgq/ar kaS82TpXlNVGTxNRg4uAUAhz87JAzB3ciumCCYZuU++q1RrUmaHeaZT69QaonN0d0Ud+Xmyn+uT tgCE8KmafIVmvgfnmcO2+3/RZGyC41wIBFFlQ9nf5lhfg1e+sYaJW9um4MM4Cm+tokJgRvm138M m2f14G4w1sSAD5Nqt+NJcSkzOZz+ZAPI06s6sIxO9mn3qRK55SdMshskj9QViou+RpnTdAQsF/q 1jUqTMVHCufKsDGhF0TE8vUseIFGOqAIgsZhkRG8UV6Fyehq2p7pB3RY+Nj92E= X-Proofpoint-GUID: KMt2oTLLQNiMj3qhGy3gVmc6BIEaHwe- X-Authority-Info-Out: v=2.4 cv=TP5Iilla c=1 sm=1 tr=0 ts=6ae0dea2 cx=c_apl:c_pps:t_out a=9mRn2PO/+PIrVdEbaIuMPg==:117 a=9mRn2PO/+PIrVdEbaIuMPg==:17 a=kj9zAlcOel0A:10 a=660iZSQnnn4A:10 a=VkNPw1HP01LnGYTKEx00:22 a=RR-qmMKWlP9b1eBdCrsA:9 a=CjuIK1q_8ugA:10 X-Proofpoint-ORIG-GUID: KMt2oTLLQNiMj3qhGy3gVmc6BIEaHwe- X-JNJ: AAAAAAABWECauvH17jm9dM47n7GYn3DCOyOeNb4QwL+110eYu/LBrEj20C5N37BxO4QTlHFGHZOLGBGO6wtSoYnn6Nl+OBpQ6Gg7I597ANMlHtMqu0KY30UKtyj4g/KRZ0F5Po8uZyASQ3Qk4xcusCij3ua6BMk5F09sh3+mAfjRvJUyN4IcFLuq50UDf5+JEQGM0jHlQGQmH9WKc+gsM8qjU6wuQ03fFVwltCtzdk0J8swtfEjtsP2XKZ2cADarNJtLhV0d0WWN4bY2ghh0Adtut9WXUIpzC/2xPugN6yS63ICBqG3gss3BhJbTnCwph+vsAPuQJ9Hs9FitkA47Fs3IA2e2AkxPgpRk6APb6+9tt2fNeda9mWB5oetSfSe88SxEgQt/O3ZRY5P0WvA4lp17ToW7uPwy9OERGOTapM2UTQioQokiMxJbCWKq1V0iDHmmPOjIxheEo/DbP38DhtEZF2F3XWeapnSqROohyiNzZhLVQoprmxWoTjj2FNRfVVsE/UYlfKwU2RTh9ejWOn74jVPRfw/CmBG1cHJNpMHpGvGGc/AST/KWuWiNwplGsm8LYMd/4Tq7W50EkPVDDNsG26NxO6nv2nI+v7tY/V01pbfIVrLI5kg0flmgaSfFKkTRGpDMr0/VGsjnhWksfbeRIdFfFjVyD/86wwlF6e2zz1yf6R1qMNTzltz9XlxVgSdE2yMiHoekL7Os2JbpMMhxkjpoqvUQ65T52j4/6BcMckbZXsv4w/eUW0nGrXLxmLNp+cHSiZ9r3iJ0hrvG2sA26/1TxGMXKMOdGNZxI3sHwHHIgSnqTRquvEjzYGMT3IFRY0SSyFXzAp0CpT5Tt+Zj0ClFgO0iorKeJh+5FyBJnjovog4PSqo7ODXWMHMAZV9iDza1GnwNj+kJEhp2WbVVu7GiQenQPWhwQaOZLz48HjCVAjeow1M4l2DjNMZlknLKLV+9JruzlcTl5/Sv2/8UqTqdh0+ o92HYKSrZDl+rcwrRclYBhY+mQEiJZWCE4YkOZCTanap5mXkBNoTxs8aYK+tgrQ+QY3CRXOzedm6pafGwpHRufV/YX5vMYH4RFvhjaXiSO1xXWDd8R0l8E4gO7zI8plVaVaUHk0pmSCwdbMQ23q8Ob3h6qAL2mjxvBhkrE2dIP/d+wvQLUCnX3vaZ7Tve7LbUv9QUfT1hbz3hwxiGn23ODB4rYXgm+ex8dPCkngj/qa3VaI2ibcBJTHjP1qhA10I3EEc8NDEhdcTyLewh5tBlnLAq+sMSj+iZ2lgTWFUfJH8GlWU5erAA+pm2PmGvVK3Vkg+KtakyvnE8266fqUiHB0Y= X-MailFrom: dev@haytok.jp X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation Message-ID-Hash: V2IMOS2UPRFIKRNCVN3TXXQIXK4YIIR2 X-Message-ID-Hash: V2IMOS2UPRFIKRNCVN3TXXQIXK4YIIR2 X-Mailman-Approved-At: Tue, 27 Oct 2026 19:57:08 +0100 CC: David Gibson , 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: Hi Stefano, Thanks for the detailed explanation, and for the background on the original design! > We're not sure whether a rollback after 2. would work: forwarding rules > that might have worked earlier might not work now (for example because > host addresses changed). > > However, in a general case, I guess that the existing (old) rules are > still more likely to work than not. That is, given: > > a. new forwarding rules don't work because of an unintended > configuration error > > b. old forwarding rules wouldn't work anymore if re-applied because of > a setup change > > I think a. is much more likely, so a rollback would be beneficial and > give the user the chance to look at possible configuration errors > without switching to a possibly unintended state. What do you think? I strongly agree. In practice, a. is far more likely. Case b. can happen depending on what changed on the host, but that's beyond what pasta can handle, so all we can do is report it and let the user fix the setup. > 1. abort on any failure of fwd_listen_init() (maintaining the current > behaviour of fwd_listen_sync_()), and: > > 2. close any listening sockets (first part of fwd_listen_switch()) that > we might have just opened > > 3. swap the rules again (as you can see, we already preserve the old > rules, because we planned to complete the rollback implementation at > some point) > > 4. call fwd_listen_init() on the old rules I agree, and that's what my work-in-progress patch does. > 5. make sure we report failure to the client Here's how I'm thinking of implementing this. Please let me know if I got something wrong: - make fwd_listen_switch() return an int, distinguishing the case where we rolled back to the old rules from the case where the rollback failed too - in conf_handler(), write that result to the control socket right after fwd_listen_switch(), before conf_close() - in pesto, read it after send_conf(), and if the update failed, print that the old rules were restored and exit non-zero For the content, I'd start with a status only (success / rolled back / restore failed). fwd_sync_one() already logs which rule failed on the pasta side, so returning that to pesto could be added later if needed. Since this adds a message from the server, we need to bump PESTO_PROTOCOL_VERSION to 3, and have pesto skip reading the result if the server version is below 3. Is that OK? I'm planning to send 5. as a separate patch from the rollback (1. to 4.). > ...this looks reasonable to me and better than the existing behaviour, > but it's pointless to do this if we want to finish things up and add > the rollback for this case. Agreed, I'll drop this patch. I was already planning to implement the rollback feature, and I have a work-in-progress patch covering steps 1. to 4. you listed. I'll send it once it's ready. Thanks, Hayato