From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 011049C90; Thu, 25 Jun 2026 02:04:05 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id D0F469BE8; Thu, 25 Jun 2026 02:04:01 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DMARC_PASS,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=4.0.1 Received: from mail-yx1-xb12f.google.com (mail-yx1-xb12f.google.com [IPv6:2607:f8b0:4864:20::b12f]) by atuin.qyliss.net (Postfix) with ESMTPS id D15B59BE6 for ; Thu, 25 Jun 2026 02:03:59 +0000 (UTC) Received: by mail-yx1-xb12f.google.com with SMTP id 956f58d0204a3-6647a6c1f0cso1126816d50.2 for ; Wed, 24 Jun 2026 19:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782353038; x=1782957838; darn=spectrum-os.org; h=autocrypt:in-reply-to:content-language:references:cc:to:subject :from:user-agent:mime-version:date:message-id:from:to:cc:subject :date:message-id:reply-to; bh=UyKx+4P6RWK9mqn8C6dUQLeKxjGUUWOODoWr1UvY3sY=; b=NCLa2WuNU1N8BsyxF6SmJdLyahNmDdeKos2JTt8NRPlb+LZ7OluaOWHH/ur7NXw45x McRoqXIUbXrNEA+68TVdvteGnI41T5z/XitBjcmko+gAihtXf9RH95/GFa7OQwomQJKw Cwsav4BaAchANEO7oevoVD5QCy+t7ohPP7GzAjxLaKOAbwCWg0pDA3+F5A8kbMtIBbp3 6e9tCprH9h8nj9ZWvzRTRylj5/DlBrK2XOBbn0hGlmpVXeX9hTTRW17mKblj9n36Np8k U3Jeva6p8ZfpJpH1QcNCQpuEONW4p+CNbFcW3x9ypvQWvs+VBUbQ9i1JIyrM5hK3TSde TS7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782353038; x=1782957838; h=autocrypt:in-reply-to:content-language:references:cc:to:subject :from:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=UyKx+4P6RWK9mqn8C6dUQLeKxjGUUWOODoWr1UvY3sY=; b=eA2cU6fwCrQPQy+vrpCWMi6/YRYzp1AEX33rGRfEOonXT/MS3HhkkBcSokI2Vg6Xqu 9PhWvaij1J9wOF6rmCwNqVgj7fnyKiAjHsR6rmrm4Dr9T4TStSOeH3A+GMjtLABFSczd VXACRMxjTxHdsI8fMMrUjihAqF9BMVWqORgC4W5vmmfo6OpLZifAvB1j4VpLrkeX7PYO BR3u3xqM7zVPFiFGpfdJ8oWF1TEiVdx1+hEXU3UuPZgmIpv4M2TOD7/e9tOKbbIA2+9u zDc6dCZppDyr5Ok/wVV+idBE5PJbLCl8rJ1cjKgMLrdjNBpGFBfsU9FOX3yBBuTLW9Xc FwuA== X-Gm-Message-State: AOJu0YzJge5trAB++WMdajKkzOOSb0fPb6P0V5hQPnSsbrb3IpZ0IMf7 d1B0BQfGaOCaGXGP36R/dvHD8YiSp66O0LjkGDJ0drrQx/G9TNujHPE/C4rTUA== X-Gm-Gg: AfdE7ckHoeS8+yEBFwETugthjHi4dhUQRQSld8u1LxXuLvLeViKu3SORnoD5VeIxOgy 83ID7RBMr7vaf4hiukKbQkX3dleAxHTeh/mpjLCNSlWTJjhx9ghdEFMQeYKrxWMmyeSuCih0mHs wY5jYIHNeJqWumHMnzYI45JaWL63XKd/w9cvHdaAEinKv94htWFrcg5BqNXqYi+y28Mw9rfvKZb O0BVvar7NPS8fmIJte144JTB4O14pxjDryvzpA9w1INY+rGsLY8KA5mNP8Uulmt7ND5G7OlUDck I3euqNxsv/YO4GRr/RJpJMcRq81pyismNkCJqEHgVyTesamWxVBYCqsWm/y6Fu1AKlOYumAfKJt /ToSm1FqRLgKnJMuXhXf2o9l3901ZskZj1CRK3O2KE/GSs+I4m08k7kt6fTyAZYcIRDzPOIWweI 0ESUxr8Dus2qVDhZfFZTpd1lMdmWSxdBhbwYvrkhK9/FHursHejQHM0ogmfsQWBpE1EnT/AMWCT +0mWpjGQpjk9Sbzub7ZUo6qDzBr X-Received: by 2002:a05:690e:124a:b0:660:a41d:d175 with SMTP id 956f58d0204a3-66488421e8dmr344551d50.55.1782353037770; Wed, 24 Jun 2026 19:03:57 -0700 (PDT) Received: from [10.138.34.110] (h69-131-147-66.cncrtn.broadband.dynamic.tds.net. [69.131.147.66]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-6647f741290sm719633d50.3.2026.06.24.19.03.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jun 2026 19:03:56 -0700 (PDT) Message-ID: Date: Wed, 24 Jun 2026 22:03:52 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Demi Marie Obenour Subject: Re: [PATCH v2] Set up control groups for most services To: Alyssa Ross References: <20260620-cgroups-v1-1-0e5abf35101b@gmail.com> <20260620-cgroups-v2-1-ccae224b6c85@gmail.com> <87qzlw5e65.fsf@alyssa.is> Content-Language: en-US In-Reply-To: <87qzlw5e65.fsf@alyssa.is> Autocrypt: addr=demiobenour@gmail.com; keydata= xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+ VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/ 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E +MYSfkEjBz0E8CLOcAw7JIwAaeBT Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------cP0SUc846MaSapvaRSYPjcK8" Message-ID-Hash: LXEHEGC65WDT64S4MYGY6W7SZIDYGKT5 X-Message-ID-Hash: LXEHEGC65WDT64S4MYGY6W7SZIDYGKT5 X-MailFrom: demiobenour@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-devel.spectrum-os.org-0; header-match-devel.spectrum-os.org-1; header-match-devel.spectrum-os.org-2; header-match-devel.spectrum-os.org-3; header-match-devel.spectrum-os.org-4; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Spectrum OS Development X-Mailman-Version: 3.3.10 Precedence: list List-Id: Patches and low-level development discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------cP0SUc846MaSapvaRSYPjcK8 Content-Type: multipart/mixed; boundary="------------waB8xd9Z7Gi2IKAOYq2u1CIk"; protected-headers="v1" Message-ID: Date: Wed, 24 Jun 2026 22:03:52 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Demi Marie Obenour Subject: Re: [PATCH v2] Set up control groups for most services To: Alyssa Ross Cc: Spectrum OS Development References: <20260620-cgroups-v1-1-0e5abf35101b@gmail.com> <20260620-cgroups-v2-1-ccae224b6c85@gmail.com> <87qzlw5e65.fsf@alyssa.is> Content-Language: en-US In-Reply-To: <87qzlw5e65.fsf@alyssa.is> Autocrypt: addr=demiobenour@gmail.com; keydata= xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+ VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/ 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E +MYSfkEjBz0E8CLOcAw7JIwAaeBT Autocrypt-Gossip: addr=hi@alyssa.is; keydata= xsFNBFpSgoYBEAC4xkCYidG2JlRWulUkTWcx0pHFDf3oSbb6Q872Kb3iDChWgluNVz43hva1 3xfDo9foV0GoyfGl/ycSCkXX5hlQr7ir/5FN38E7H/yY6tH8+l68iDgIOcb1qY0OYaxyg+Lz WesfFQedrmwNTbF4L1BtWzrTR5PflDdhDo5VWSguHGJFSclchcr/6UmMb/gOUN+2ElBC2TE2 EKY099phZ6DJZ2aZCsclwKIdCpZzXlEmXPAeaH5om6xo90JYv5+sFji40R0Plqec3WC+jTxy lGca6IbPdOminuUF+GvsR86eVsgh/0XNK7/zus7gyc4PuMUA1rCoeHcWOBDPgmelgCQyJGXd /bXeKuUsGoge58uc7/YNvOh1vfpD3AaEMqAyXfmmUwBnIicml74+2eOpH3Oljfs01g+DhkOB MtpVSZSgaIDvP0WG6cbAxImoUasnmNxEDNskfVmI8bsajPW9bt4z5hiP5Q9G3vE0D5HcIFdM adOz81PpOwNiUXcjtYV1PWZQ56jbSTOf8EBvsB71WwB+XgVWcPzIlY8hAykiHIO87oV3o71U JTAn1Foj7mjSADnY0deleOmar/K5jrK3wvKKM1XlB7PXcGBdkorJC+cbxVsw0ADzMw0c7bVc wEE7OFvHjQiIK1lO+lb1cvGBBY3IZxjsjZdA/VsFHFdAeYlzNQARAQABzRpBbHlzc2EgUm9z cyA8aGlAYWx5c3NhLmlzPsLBlwQTAQgAQQIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAIZ ARYhBHVzVtd5u7iIdz5BXnNszfnvUb2XBQJp+DXpBQkQHFpjAAoJEHNszfnvUb2XyMsP/0b3 VfbvrD6u4ohdpoFhBTaacnMaZVBKr8yHMpD/YFKO3dM5nqne92uoauy5RBknH2gQg667gWtZ KpnqgKnV8JCswyepmLqRdJwLnPpQUri5c089QZHVSvjrSXOtcU9MqVA/fU5pHh2j06I1mrEy A8uZ5GWqjBwshAI+JmP2uEeEURCQi5XcNso92r//Q3tPm6QhF3B3hbfqZ31Qx17/4Unh6f4/ 8XY9RxXoVLuMQpYXd1lqXwH8+QF0aTXoRuR/p48dV6DpxU7arVvZMpJ5WAzPTcQ7VdJjTkVR nWPJ4f1Keun+Y3FkBg4vc3ADqKtNZ4eyTaG7DBD5jBMMLS9KYZM9bzT5Y8eNj6JbqB8JVdS6 PwHMlBnYhp5v2z9BboyUiNiQPN9oh0ONV9yVMV5wLr5JUofvoMz4pYdaysyCoPaSoR2BYqWN HDnqdBvVQqdae8a5cbTPDpiqrT0yy3KQGR+iGqIHa5fzibc755RNzikuDYXC4Rovy7Tsrog5 rV869o1RMTIxp/vgLm3v8/ZLkNabIpb3UdsnUp+NyvQNXuSZ6mkO4wALVkv+Yud0sqUhtRQJ gOpEiEg4DVP92JVBeIM7qpfvmdgP6Z9rTPq7nXEZ6MkCfMolkc1TBoFkNHxIDCCoEKgtESK4 jVRVTXT/zUGZaTJQ0OK08jSPNjWGZGnvzjgEZyd/yxIKKwYBBAGXVQEFAQEHQCVxoiHOlsEo NDKGCbxg4nL3E1CV0MRQCU1hPowd77h3AwEIB8LBfAQYAQoAJgIbDBYhBHVzVtd5u7iIdz5B XnNszfnvUb2XBQJp+DXlBQkDR10PAAoJEHNszfnvUb2XRjYQAKOyORIaAhTyKPAX3SezjFWH NK1jjtSyL23dnHENbmtYoi0tL/P3cF1PEskT/mJZ6A/ON4lb1Lh84Ux1yG+lGq7wIXIY4RFC 1dYCQdCa7YKRTxrw6hyuGkJlwTbdCx1rzA4F7JEpI3VV2s2xIcuonMszxslKvaYCvtNLdy6A a87oGEdTadCfdm7w1O2YfnMR/XiEHH37jXOPz9zMuBoVpU5pj0DzFrN17vPNwdumgQ6QAfdL Xe7suys1hHarqBClX+d2qpj0OI/Bc5nhto2Melhw8V1t57fNIGlSt812+dcp5TK3DWsc1InA FOfEo7LLpcptLdM86/3gwul4DqRm9MYIDWnRxdobi9/2Uk7O9412lfakYN0/ap70a6eHn0Ht SfGShJfpGDSG13Gy8XfgBNb3tpI39kNNzGfl1i3xscsIyzs6oLrngnH3lnrqyN/ss0a11Knj QK+j47whKVBuxT5ZN6slPApn9yv9htZVZlSMXbMUrnkMuP0WSERjC63S9+x2SDgJOM76DpAt tEX6QaY4Yd7gQgLnQVR/q9duQz+jnawc9NApS9T5t5XNqfVOPzns7mLa9FU1L/+lhpmpSIO5 G36q4gc2EX58JAXXqU+RXStAd9L86KyynIsnMD0jf9k4VN466Ew5WXbDjeucltEG0ZMg0WxO PMu8tBGvtGVA --------------waB8xd9Z7Gi2IKAOYq2u1CIk Content-Type: multipart/mixed; boundary="------------HtqzBRGgW88x8M0vU9uo53Ts" --------------HtqzBRGgW88x8M0vU9uo53Ts Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/24/26 08:13, Alyssa Ross wrote: > Demi Marie Obenour writes: >=20 >> The cgroups are handled by a Rust tool. The name of the cgroup is >> autogenerated from the service name. >> >> Using cgroups for process control is not implemented yet. >> >=20 > Perhaps you could include some more details of how the cgroup hierarchy= > is supposed to be set up and why, either in the patch body or in > documentation? Will fix in v3. > As I understood it, the point of using cgroups was that we could bundle= > all services for a VM, including the VMM, into a single cgroup, but I > don't see that here, just a pure translation of the service hierarchy > (which the VMM might not even be part of). Are per-VM cgroups coming > later? I think it would be significantly simpler to have the VMM be just another VM service. This would naturally put it under the vm-services cgroup, solving this problem. Since this would mostly involve changes to execline scripting, I think it would be better if you wrote this code. >> diff --git a/host/rootfs/image/etc/fstab b/host/rootfs/image/etc/fstab= >> index 18bb5e45abafeaf43871306ce8233239e5c07f76..d92364d83f4d26f766fcd5= b494614c06a630d2fe 100644 >> --- a/host/rootfs/image/etc/fstab >> +++ b/host/rootfs/image/etc/fstab >> @@ -6,3 +6,4 @@ tmpfs /dev/shm tmpfs nosuid,nodev 0 0 >> tmpfs /media tmpfs nosuid,nodev,noexec,nosymfollow,mode=3D755 0 0 >> sysfs /sys sysfs nosuid,nodev,noexec 0 0 >> tmpfs /tmp tmpfs nosuid,nodev 0 0 >> +cgroup2 /sys/fs/cgroup cgroup2 nosuid,nodev,noexec,nosymfollow 0 0= >=20 > Alignment is off here. The rest of the file uses tabs at 8 characters.= > (I know, I know, but it's traditional.) >=20 >> diff --git a/host/rootfs/image/etc/s6-linux-init/run-image/service/ser= ial-getty-generator/run b/host/rootfs/image/etc/s6-linux-init/run-image/s= ervice/serial-getty-generator/run >> index bf66ab0878fc6d8e77ca71a4a89e50c139a6bb11..5c9988c994ed9b94232905= 5673b332d0aa918957 100755 >> --- a/host/rootfs/image/etc/s6-linux-init/run-image/service/serial-get= ty-generator/run >> +++ b/host/rootfs/image/etc/s6-linux-init/run-image/service/serial-get= ty-generator/run >> @@ -1,7 +1,8 @@ >> -#!/bin/execlineb -WP >> +#!/bin/execlineb -WS1 >> # SPDX-License-Identifier: EUPL-1.2+ >> # SPDX-FileCopyrightText: 2024-2025 Alyssa Ross >> =20 >> +cgroup-setup -- $1 >> piperw 3 4 >> background { >> fdclose 3 >=20 > What benefit does this cgroup provide? None, I'll remove it. The only requirement of the current code is that if a service is under a cgroup, its parent should *also* be under a cgroup. Otherwise you can get conflicting cgroup paths. >> diff --git a/host/rootfs/image/etc/s6-linux-init/run-image/service/ser= ial-getty/run b/host/rootfs/image/etc/s6-linux-init/run-image/service/ser= ial-getty/run >> index 78f794202bf174f3c036f3e20755ac087a988277..ed0808b9e45b077023f237= a0f9c0e5c830015ac2 100755 >> --- a/host/rootfs/image/etc/s6-linux-init/run-image/service/serial-get= ty/run >> +++ b/host/rootfs/image/etc/s6-linux-init/run-image/service/serial-get= ty/run >> @@ -1,5 +1,6 @@ >> -#!/bin/execlineb -WP >> +#!/bin/execlineb -WS1 >> # SPDX-License-Identifier: EUPL-1.2+ >> # SPDX-FileCopyrightText: 2023 Alyssa Ross >> =20 >> +cgroup-setup -- $1 >> s6-svscan -d3 instance >=20 > We're putting supervisors of instances services in a cgroup? Can you > explain to me why that's useful? This allows configuring limits that apply to the whole instance, and means that the whole instance can be reliably killed. Services spawned by the instance will be in their own sub-cgroups, so one can apply separate limits to them so long as those limits do not exceed those of the containing cgroup. The hierarchy works like this: /sys/fs/cgroup service1.service @inner.service # processes go here service2.service @inner.service # and here service3.service @inner.service # and here You can apply resource limits at any level of the hierarchy. Limits in nested cgroups can be smaller but not larger. Terminating processes in a cgroup with cgroup.kill also terminates all processes in child cgroups. After terminating the processes in a cgroup, cgroup-setup will delete everything in the hierarchy recursively. >> diff --git a/tools/cgroup-setup/Cargo.toml b/tools/cgroup-setup/Cargo.= toml >> new file mode 100644 >> index 0000000000000000000000000000000000000000..9cce0be706151dfd5264a8= 1afb3ee9a6c851367c >> --- /dev/null >> +++ b/tools/cgroup-setup/Cargo.toml >> @@ -0,0 +1,17 @@ >> +# SPDX-License-Identifier: CC0-1.0 >> +# SPDX-FileCopyrightText: 2025 Alyssa Ross >> +# SPDX-FileCopyrightText: 2026 Demi Marie Obenour >> + >> +[package] >> +name =3D "cgroup-setup" >> +edition =3D "2024" >> + >> +[dependencies] >> +libc =3D "0.2.177" >> +rustix =3D { version =3D "1.1.2", features =3D ["fs"] } >> + >> +[profile.release] >> +split-debuginfo =3D "symbols" >> +strip =3D "symbols" >> +lto =3D true >> +panic =3D "abort" >=20 > What's with all this stuff? Why do we set it only for this program, an= d > not for any others? Please don't introduce divergence in build setting= s > between programs without a good reason. I was trying to reduce the binary size as it seemed rather bloated. I'll leave them out=20 >> diff --git a/tools/cgroup-setup/src/cgroup.rs b/tools/cgroup-setup/src= /cgroup.rs >> new file mode 100644 >> index 0000000000000000000000000000000000000000..cd77becc0b40bfdcd983e5= 3b63b7c21e4308d5fc >> --- /dev/null >> +++ b/tools/cgroup-setup/src/cgroup.rs >> @@ -0,0 +1,181 @@ >> +// SPDX-License-Identifier: EUPL-1.2+ >> +// SPDX-FileCopyrightText: 2026 Demi Marie Obenour >> + >> +use std::fs::File; >> +use std::io::{Read, Seek}; >> +use std::os::fd::{AsFd, OwnedFd}; >> +use std::os::fd::{AsRawFd, BorrowedFd}; >> + >> +use std::path::{Path, PathBuf}; >> + >> +use rustix::fs::AtFlags; >> +use rustix::path::Arg; >> +use rustix::{ >> + fs::{Mode, OFlags, ResolveFlags}, >> + io::Errno, >> +}; >> + >> +pub(crate) struct LeafCgroup { >> + path: PathBuf, >> + fd: OwnedFd, >=20 > root_fd would be a clearer name, if I'm understanding correctly. It's the FD for the cgroup directory, but not for the root of the cgroup tree. >> +} >> + >> +enum Access { >> + Read, >> + Write, >> +} >=20 > Given this isn't public, it doesn't seem to add any value over passing > around OFlags::RDONLY and OFlags::WRONLY directly. Will change in v3. >> + >> +impl LeafCgroup { >> + fn open_subtree(&self, path: &std::path::Path, access: Access) ->= Result { >> + rustix::fs::openat2( >> + self.fd.as_fd(), >> + path, >> + OFlags::NOATIME >> + | OFlags::CLOEXEC >> + | OFlags::NOFOLLOW >> + | match access { >> + Access::Write =3D> OFlags::WRONLY, >> + Access::Read =3D> OFlags::RDONLY, >> + }, >> + Mode::empty(), >> + ResolveFlags::NO_SYMLINKS | ResolveFlags::BENEATH | Resol= veFlags::NO_XDEV, >> + ) >> + } >> + >> + pub fn kill_processes(&self) -> std::io::Result<()> { >> + let kill_fd =3D self.open_subtree(std::path::Path::new("cgrou= p.kill"), Access::Write)?; >> + let wait_file =3D self.open_subtree(std::path::Path::new("cgr= oup.events"), Access::Read)?; >> + let poll_fd =3D wait_file.as_raw_fd(); >> + let mut wait_fd =3D File::from(wait_file); >> + assert_eq!(rustix::io::write(kill_fd.as_fd(), b"1")?, 1, "ker= nel bug"); >> + let mut fds =3D libc::pollfd { >> + fd: poll_fd, >> + events: libc::POLLIN | libc::POLLPRI | libc::POLLRDHUP, >> + revents: 0, >> + }; >> + // SAFETY: FFI call, valid arguments, fds contains 1 element >> + let mut v =3D vec![]; >> + 'a: loop { >> + v.clear(); >> + if unsafe { libc::poll(&raw mut fds, 1, -1) } !=3D 1 { >> + panic!("poll failed"); >> + } >=20 > Shouldn't we start polling before writing? Otherwise we might miss the= > notification, if it comes in between the write and the poll. I'll test this, but I think it shouldn't matter. If it does matter, I'll= need to switch to epoll (or io_uring, but that's overkill here). >> + wait_fd >> + .seek(std::io::SeekFrom::Start(0)) >> + .expect("Seek on control group file should succeed");= >> + wait_fd >> + .read_to_end(&mut v) >> + .expect("reading from control group should work"); >> + for substr in v.split(|&c| c =3D=3D b'\n') { >> + if substr =3D=3D b"populated 0" { >=20 > Could do this in one line, and avoid the labelled break: >=20 > if v.split(|&c| c =3D=3D b'\n').any(|line| line =3D=3D b"populated 0") = { >=20 > (I think "line" is a clearer name than "substr".) Will fix in v3. >> + break 'a; >> + } >> + } >> + } >> + Ok(()) >> + } >> +} >> + >> +impl AsFd for LeafCgroup { >> + fn as_fd(&self) -> std::os::fd::BorrowedFd<'_> { >> + self.fd.as_fd() >> + } >> +} >> + >> +impl LeafCgroup { >> + pub(crate) fn open_cgroup_at(&self, p: &Path) -> Result { >> + let fd =3D rustix::fs::openat2( >> + self.fd.as_fd(), >> + p, >> + OFlags::NOATIME >> + | OFlags::CLOEXEC >> + | OFlags::NOFOLLOW >> + | OFlags::RDONLY >> + | OFlags::DIRECTORY, >> + Mode::empty(), >> + ResolveFlags::NO_SYMLINKS | ResolveFlags::BENEATH | Resol= veFlags::NO_XDEV, >> + )?; >> + Ok(Self { >> + fd, >> + path: self.path.join(p), >> + }) >> + } >> + pub(crate) fn open_cgroup(fd: BorrowedFd, p: &Path) -> Result { >> + let fd =3D rustix::fs::openat2( >> + fd, >> + p, >> + OFlags::NOATIME >> + | OFlags::CLOEXEC >> + | OFlags::NOFOLLOW >> + | OFlags::RDONLY >> + | OFlags::DIRECTORY, >> + Mode::empty(), >> + //ResolveFlags::NO_SYMLINKS | ResolveFlags::BENEATH | Res= olveFlags::NO_XDEV, >=20 > Stray comment. Will fix in v3. >> + ResolveFlags::NO_SYMLINKS, >> + )?; >> + Ok(Self { >> + fd, >> + path: p.to_owned(), >> + }) >> + } >> + pub(crate) fn make_child(&self, p: &Path) -> Result<(), Errno> { >> + rustix::fs::mkdirat( >> + self.fd.as_fd(), >> + p, >> + Mode::RUSR >> + | Mode::WUSR >> + | Mode::XUSR >> + | Mode::RGRP >> + | Mode::XGRP >> + | Mode::ROTH >> + | Mode::XOTH, >> + ) >> + } >> + >> + pub(crate) fn delete_child(&self, path: &Path) -> Result<(), Errn= o> { >> + remove_all(100, self.as_fd(), &path.as_cow_c_str().unwrap()) >> + } >> +} >> + >> +fn remove_recursively(fd: OwnedFd, remaining_depth: usize) -> Result<= (), Errno> { >> + if remaining_depth < 1 { >> + panic!("control groups too deeply nested"); >> + } >> + let mut d =3D rustix::fs::Dir::new(fd).expect("cannot start itera= ting"); >> + while let Some(element) =3D d.next() { >> + let element =3D element.expect("Iterating through a cgroup di= rectory failed?"); >> + if element.file_type() !=3D rustix::fs::FileType::Directory {= >> + continue; >> + } >> + >> + let remaining_depth =3D remaining_depth - 1; >> + let d: &rustix::fs::Dir =3D &d; >> + let dirfd =3D d.fd().unwrap(); >> + let path =3D element.file_name(); >> + remove_all(remaining_depth, dirfd, path)?; >> + } >> + Ok(()) >> +} >> + >> +fn remove_all( >> + remaining_depth: usize, >> + dirfd: BorrowedFd<'_>, >> + path: &std::ffi::CStr, >> +) -> Result<(), Errno> { >> + if path =3D=3D c"." || path =3D=3D c".." { >> + return Ok(()); >> + } >> + if rustix::fs::unlinkat(dirfd, path, AtFlags::REMOVEDIR).is_ok() = { >> + return Ok(()); >> + } >> + let fd =3D rustix::fs::openat2( >> + dirfd, >> + path, >> + OFlags::NOATIME | OFlags::CLOEXEC | OFlags::NOFOLLOW | OFlags= ::RDONLY | OFlags::DIRECTORY, >> + Mode::empty(), >> + ResolveFlags::NO_SYMLINKS | ResolveFlags::BENEATH | ResolveFl= ags::NO_XDEV, >> + )?; >> + remove_recursively(fd, remaining_depth)?; >> + rustix::fs::unlinkat(dirfd, path, AtFlags::REMOVEDIR)?; >> + Ok(()) >> +} >> diff --git a/tools/cgroup-setup/src/main.rs b/tools/cgroup-setup/src/m= ain.rs >> new file mode 100644 >> index 0000000000000000000000000000000000000000..358703a73fcbdc38794312= fe3987e733f37c2df0 >> --- /dev/null >> +++ b/tools/cgroup-setup/src/main.rs >> @@ -0,0 +1,196 @@ >> +// SPDX-License-Identifier: EUPL-1.2+ >> +// SPDX-FileCopyrightText: 2026 Demi Marie Obenour >> + >> +use std::{ >> + ffi::{OsStr, OsString}, >> + fs::File, >> + io::Write as _, >> + os::unix::prelude::*, >> + path::{Component, Path, PathBuf}, >> +}; >> + >> +use rustix::{ >> + fs::{FlockOperation, Mode, OFlags, ResolveFlags}, >> + io::Errno, >> +}; >> + >> +mod cgroup; >> + >> +macro_rules! fail { >> + ($($arg:tt)*) =3D> {{ >> + eprintln!($($arg)*); >> + std::process::exit(1)} >> + }; >> +} >=20 > I'd find the error handling Rustier if we did error returns with the ? > operator, like how mount-flatpak does it. The error type can just be > String. Sure! >> + >> +fn main() { >> + let mut args =3D std::env::args_os(); >> + let Some(prog_name) =3D args.next() else { >> + fail!("No command line arguments (argv[0] is NULL)"); >> + }; >> + let mut cgroup_relative_path =3D args.next(); >> + if cgroup_relative_path.as_deref() =3D=3D Some(OsStr::from_bytes(= b"--")) { >> + cgroup_relative_path =3D args.next(); >> + } >=20 > We could just not support -- and simplify invocation, right? Only if we never want to support any options in the future. >> + >> + let Some(cgroup_relative_path) =3D cgroup_relative_path else { >> + fail!("{prog_name:?}: Have no positional arguments, expect at= least 1") >> + }; >> + let mut cgroup_relative_path =3D cgroup_relative_path.into_vec();= >> + >> + // slow but we do not care >=20 > Slow? O(n) for a size-n Vec. Not something you want in a hot path, but fine he= re. >> + if cgroup_relative_path.len() > 247 { >=20 > This magic number could perhaps use a name. Sure. >> + fail!("{prog_name:?}: Cgroup name {cgroup_relative_path:?} to= o long"); >> + } >> + if cgroup_relative_path.is_empty() { >> + fail!("{prog_name:?}: Cgroup name {cgroup_relative_path:?} em= pty"); >> + } >> + if cgroup_relative_path[0] =3D=3D b'-' { >> + fail!("{prog_name:?}: Cgroup name {cgroup_relative_path:?} st= arts with '-'"); >> + } >=20 > Is that a problem? In theory, no, but it's probably a bug in the caller. >> + for &i in &cgroup_relative_path { >> + match i { >> + b'/' =3D> fail!( >> + "{prog_name:?}: Cgroup name {cgroup_relative_path:?} = \ >> +contains /" >> + ), >> + b'$' =3D> fail!( >> + "{prog_name:?}: Cgroup name {cgroup_relative_path:?} = \ >> +contains $: did you forget an execline substitution?" >> + ), >> + b'!'..=3Db'~' =3D> {} >> + _ =3D> fail!( >> + "{prog_name:?}: Cgroup name {cgroup_relative_path:?} = \ >> +contains space, non-ASCII character, or control character (byte {i})"= >> + ), >=20 > Surely every kernel interface we're going to use is 8-bit clean. If > this is about log viewing again, I really don't like it. Even if we're= > careful about it in first-party code (which itself is a big ask), we > can't expect it of every other package that might log something. Peopl= e > viewing logs have to use robust tools to do so regardless, or we have t= o > mitigate this somewhere centrally, e.g. in s6 log. Doing this piecemea= l > does not meaningfully mitigate the problem, and arguably creates a fals= e > sense of security. This was inspired by systemd, which has restrictions on what characters are allowed in service names. Also, restricting allowed characters makes it easier to find bugs, such as "${a} ${b}" instead of "${a}" "${b}" in an execline script. Forbidding '$' is very much intentional, and is inspired by me making the exact mistake described by the error message. It also means that certain names can be reserved for internal use. >> + } >> + } >> + cgroup_relative_path.extend_from_slice(b".service"); >=20 > What do we need the suffix for? The kernel may add new control files at any time. However, it will never use the .service suffix to avoid breaking systemd. Therefore, I chose to use that suffix to avoid breaking in future kernel releases. >> + let cgroup_relative_path =3D Path::new(OsStr::from_bytes(&cgroup_= relative_path)); >> + >> + let local_cgroup =3D std::fs::read("/proc/thread-self/cgroup") >=20 > Ooc, why /proc/thread-self instead of /proc/self? Why not? The two are aliases in this case, but in general /proc/thread-s= elf is likely the better choice. >> + .unwrap_or_else(|e| fail!("{prog_name:?}: cannot read /proc/t= hread-self/cgroup: {e}")); >> + >> + if !local_cgroup.starts_with(b"0::/") >> + || !local_cgroup.ends_with(b"\n") >> + || local_cgroup.contains(&b'\0') >> + { >> + fail!("{prog_name:?}: Kernel bug: Bad contents of /proc/threa= d-self/cgroup"); >> + } >=20 > We are not a kernel fuzzer. We can't reasonably write programs that > have to anticipate kernel contract violations. Fair! >> + >> + let mut local_cgroup =3D PathBuf::from(:= :from_vec( >> + local_cgroup[4..local_cgroup.len() - 1].to_owned(), >=20 > =E2=80=A6 but maybe we could make this clearer, and still satisfy your = instincts > to validate, by using slice::strip_prefix and slice::strip_suffix, > unwrapping the results? That's even better, because it's much easier to read than magic numbers. >> + )); >> + >> + match local_cgroup.components().next_back() { >> + Some(Component::Prefix(_)) =3D> unreachable!("does not occur = on Linux"), >> + Some(Component::RootDir) | None =3D> {} >> + Some(Component::CurDir) =3D> unreachable!("not produced by ke= rnel"), >> + Some(Component::ParentDir) =3D> unreachable!("not produced by= kernel"), >> + Some(Component::Normal(os_str)) =3D> { >> + if os_str.as_bytes() =3D=3D b"@inner.service" { >> + let _ =3D local_cgroup.pop(); >> + } >> + } >> + } >=20 > Could we not simplify this with local_cgroup.file_name()? If it's None= , > it's the root directory; otherwise it's the equivalent of normal. Yup! >> + >> + if local_cgroup.as_os_str().is_empty() { >> + local_cgroup =3D PathBuf::from("."); >> + } >=20 > Path::is_empty is stable in 1.98. Could we mention that in a TODO/FIXM= E > comment so we can use it when available? Will do. >> + let cgroup_root =3D rustix::fs::openat2( >> + rustix::fs::CWD, >> + Path::new("/sys/fs/cgroup"), >> + OFlags::DIRECTORY | OFlags::RDONLY | OFlags::CLOEXEC | OFlags= ::NOFOLLOW, >> + Mode::empty(), >> + ResolveFlags::NO_MAGICLINKS | ResolveFlags::NO_SYMLINKS, >> + ) >> + .unwrap_or_else(|e| fail!("{prog_name:?}: cannot open /sys/fs/cgr= oup: {e}")); >=20 > Why do we need to use openat2 for this, but not for reading > /proc/thread-self/cgroup? I'm a bit surprised to see openat2 here at > all, since only root could manipulate these paths, in which case they > have no need to use this program as a confused deputy, right? >=20 > If openat2 is to stay, isn't OFlags::NOFOLLOW redundant with > ResolveFlags::NO_SYMLINKS? openat2() is indeed pointless here. >> + >> + let cgroup =3D match cgroup::LeafCgroup::open_cgroup(cgroup_root.= as_fd(), &local_cgroup) { >> + Ok(e) =3D> e, >> + Err(e) =3D> fail!( >> + "{prog_name:?}: Failed to open {}: {e:?}", >> + local_cgroup.display() >> + ), >> + }; >> + >> + match rustix::fs::flock(cgroup.as_fd(), FlockOperation::LockExclu= sive) { >> + Ok(()) =3D> {} >> + Err(e) =3D> fail!("{prog_name:?}: cannot lock cgroup: {e}"), >> + } >=20 > Would std::fs::File::lock not be a bit Rustier? Yes :). I know how to=20 =09 >> + purge_cgroup(&prog_name, &cgroup, cgroup_relative_path); >=20 > I find it a little weird that we run this program in both service > startup and finish, when there are really two completely separable part= s > to it, right? Why is purging not a separate program that only runs in > finish? The finish script might fail, time out, etc. Purging at startup ensures that any previous cgroup state (like attached BPF programs) is removed, and it ensures that the program this program invokes will not run concurrently. It's just more robust overall. Purging is idempotent, and purging an already-purged cgroup is very cheap. Also, this allows using cgroup-setup without a finish script, while still ensuring that if the service restarts there are no stale processes left behind. >> + let Some(program_name) =3D args.next() else { >> + return; >> + }; >=20 > This could be moved closer to where it's used. Will fix in v3. >> + if let Err(e) =3D cgroup.make_child(cgroup_relative_path) { >> + fail!("{prog_name:?}: cannot create child cgroup: {e}") >> + } >> + let child =3D cgroup >> + .open_cgroup_at(cgroup_relative_path) >> + .unwrap_or_else(|e| { >> + fail!("{prog_name:?}: cannot create child cgroup {cgroup_= relative_path:?}: {e}") >> + }); >> + child >> + .make_child(Path::new("@inner.service")) >> + .unwrap_or_else(|e| { >> + fail!("{prog_name:?}: cannot create child cgroup {cgroup_= relative_path:?}/@inner.service: {e}") >> + }); >> + let child =3D child >> + .open_cgroup_at(Path::new("@inner.service")) >> + .unwrap_or_else(|e| { >> + fail!("{prog_name:?}: cannot open child cgroup {cgroup_re= lative_path:?}/@inner.service: {e}") >> + }); >=20 > This would really benefit from having been written up, so I don't have > to guess what it's for. We only really need it for supervisors, right?= It's only *needed* when the program might be called recursively, but it's easier to just use it everywhere. >> + >> + // SAFETY: safe FFI call >> + let pid =3D unsafe { libc::getpid() }; >=20 > Not std::process::id()? Only because I was not aware of it. >> + write_cgroup_value(&prog_name, &child, "cgroup.procs", &pid.to_st= ring()); >> + >> + let e =3D std::process::Command::new(&program_name).args(args).ex= ec(); >> + fail!( >> + "{prog_name:?}: cannot spawn child {:?}: {}", >> + program_name, >> + e >> + ); >> +} >> + >> +fn write_cgroup_value(prog_name: &OsStr, child: &cgroup::LeafCgroup, = name: &str, value: &str) { >=20 > Perhaps it would be nicer for this to be a method on LeafCgroup? Sure! >> + let path =3D Path::new(name); >> + let fd =3D rustix::fs::openat2( >> + child.as_fd(), >> + path, >> + OFlags::NOATIME | OFlags::CLOEXEC | OFlags::NOFOLLOW | OFlags= ::WRONLY, >> + Mode::empty(), >> + ResolveFlags::NO_SYMLINKS | ResolveFlags::BENEATH | ResolveFl= ags::NO_XDEV, >> + ) >> + .unwrap_or_else(|e| fail!("{prog_name:?}: cannot open {:?}: {}", = path, e)); >> + let () =3D File::from(fd) >> + .write_all(value.as_bytes()) >> + .unwrap_or_else(|e| { >> + fail!( >> + "{prog_name:?}: Cannot write {:?} to {:?}: {}", >> + name, >> + path, >> + e >> + ) >> + }); >=20 > Similarly to above, if we don't need openat2, this could be done more > nicely as std::fs::write. std::fs doesn't even expose openat(), and I'm much more comfortable using a directory FD here. This is a fairly severe limitation in the stdlib. Fixing it requires using the Native API on Windows, but that's easy enough. >> +} >> + >> +fn purge_cgroup(prog_name: &OsStr, cgroup: &cgroup::LeafCgroup, cgrou= p_relative_path: &Path) { >> + let child =3D match cgroup.open_cgroup_at(cgroup_relative_path) {= >> + Ok(child_cgroup) =3D> child_cgroup, >> + Err(Errno::NOENT) =3D> return, >> + Err(other) =3D> { >> + fail!("{prog_name:?}: cannot open child cgroup {cgroup_re= lative_path:?}: {other}") >> + } >> + }; >> + child.kill_processes().unwrap_or_else(|e| { >> + fail!("{prog_name:?}: cannot kill programs in {cgroup_relativ= e_path:?}: {e}") >> + }); >> + >> + cgroup >> + .delete_child(cgroup_relative_path) >> + .unwrap_or_else(|e| { >> + fail!("{prog_name:?}: delete child cgroup {cgroup_relativ= e_path:?}: {e}") >> + }); >> +} --=20 Sincerely, Demi Marie Obenour (she/her/hers) --------------HtqzBRGgW88x8M0vU9uo53Ts Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc" Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/ UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r 6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc /9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4 BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf /5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R /4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ 7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+ AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ 5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41 ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd 8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk /Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH 0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog 2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0 Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9 uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj 6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK 9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64 GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3 J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb 49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6 +3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6 synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8 N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb /Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r 8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D =3Dx94R -----END PGP PUBLIC KEY BLOCK----- --------------HtqzBRGgW88x8M0vU9uo53Ts-- --------------waB8xd9Z7Gi2IKAOYq2u1CIk-- --------------cP0SUc846MaSapvaRSYPjcK8 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmo8jIkACgkQszaHOrMp 8lP85w//VhFjaGOVnc+94MnwDtd3vsO06kKSQ286FN9LXBu5hoW+lOIJgAGw4ei7 KxVVsoHStxIgCYxXfrqrjJectASRtrHqDUGyDowSDz7bpvs41fkQB+qlzsK2l58Z DzOuvk51tWfwx44xQPL7ZRaeW+aRDCJjPK4m7sfS3WbalTnGXuS8BBtK/R50a5rq dp2LmDKV7mZBeNJ41V0Nss4Cx3DrcGlAkvlWRwcES6D+uLsgex1ggayDmXjNalWu EG6bxzVOwBOetx0zOmqJzuyzPQysU5HQV49GgRU/VeS+2D+Ayc0NhCxWvq3Z0sbH iarZC2yhqUcPYhQQ9t7i7+tYeZPkYZDrOJvpPf8kKN87rQ1SVE9a08gzbQFyU95U fvKtirUuuEu7Vc9q5ET2F9omFYTjhavo9qMUB1PTtjcOG34pio7yFWV45eEotOtJ cTrmGPlDC/Y/tsZLBmart1Z9xhvcU31Isr2dkR9MHtkPpW9Q6rtxJfeaxEGHqeNj BCDdguG4L3gRo4ydRULaXfWkUSFh9RUUBSpq+CPHsZbwmJfp+GSrxlgnYoCCjrxq PMNEkzprlNLq/4J5rl9nA0qoQnAYBRKShvt82cPpPaK/IYbPbfVsHwBKiG0a0JHA U8ZGB59TN6CVdSBS7FWsjIAIJuImqbyNRHpwDh1pcYiimbsLZVU= =sNP5 -----END PGP SIGNATURE----- --------------cP0SUc846MaSapvaRSYPjcK8--