From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26408 invoked from network); 16 Nov 2023 00:30:24 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 16 Nov 2023 00:30:24 -0000 Received: (qmail 1800 invoked by uid 550); 16 Nov 2023 00:30:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1761 invoked from network); 16 Nov 2023 00:30:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tavianator.com; s=google; t=1700094607; x=1700699407; darn=lists.openwall.com; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=xdvizxa5eyOc1Iu5KTJ05uaPA7bmTEHOA+KayK3cGGU=; b=G1NuXpigNWuU7XQf7dhSRW+nNaqLoReQOsQjKkDmvb5an63SXU3U3G7gztpWn6h45W jTiH0SSS/0FwAyDIsX10oA2gQVpSjq+q13mlmcai4s4IUF66qUMKr8oOz9h2dfAsd90q UpylSYTNMb/XHhpDhBVkNeWGBhg4XQ4EqpXrk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700094607; x=1700699407; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xdvizxa5eyOc1Iu5KTJ05uaPA7bmTEHOA+KayK3cGGU=; b=jSwaUnM9CU0NF8x42UPn/Xl1ik4LmzlU+MouGSBCdq+/vgm2adV9pWuFHsc6rj3icK Y8+hNFdIjxzIh/TyJNi5UWyXuXgdysxZBpmAwUceXXvuc4mjcijyWTl51jRewWMPvoh0 mjZCEdmGVZNcavVfQNlbMTsm6IcWqhBoZupegH0movoVbCOb0GtwbwWpE6AhBhqYBTrT re56NHSK/R+S3URLcJzSzmonxWYC4EABDcBG872tiO5AkLcZu1gIJ3hM9ya9xfyCXJM2 j1XNTARef9O1hP9nSC+7309QRnujfko5vzrZBwwsq/lbAHYjcBUtrQIQK5behGIDyVjc VzRQ== X-Gm-Message-State: AOJu0YwwK4O2ud0O6CCJ3NNGrrQ7w5nhEFo+LMmplKgctWStRSkEn5gd xLszmqoF6PTRIRJrDfSWVXeobleFRputo0XVcGk= X-Google-Smtp-Source: AGHT+IG305PWb5MYI/XRBu3m95PMG6WwZPALF7GylMSWkjS605nEgGWg4FrsZK8fsfNOwIbQV43VR0QBXeW53K1uZZY= X-Received: by 2002:a0c:efcf:0:b0:66d:fac:33f9 with SMTP id a15-20020a0cefcf000000b0066d0fac33f9mr6460546qvt.11.1700094607306; Wed, 15 Nov 2023 16:30:07 -0800 (PST) MIME-Version: 1.0 References: <20231115223902.GY4163@brightrain.aerifal.cx> In-Reply-To: <20231115223902.GY4163@brightrain.aerifal.cx> From: Tavian Barnes Date: Wed, 15 Nov 2023 19:29:56 -0500 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Feature request: posix_spawnattr_setrlimit_np() On Wed, Nov 15, 2023 at 5:38=E2=80=AFPM Rich Felker wrote= : > > On Wed, Nov 15, 2023 at 05:00:51PM -0500, Tavian Barnes wrote: > > I have a program that raises its soft RLIMIT_NOFILE, but wants to > > spawn processes with the original value (in case they use select(), > > for example). There seems to be no nice way to do this with > > posix_spawn(). I can temporarily lower the rlimit in the parent, but > > that interferes with other threads, and can make posix_spawn() fail > > with EMFILE. > > > > Corresponding glibc feature request: > > https://sourceware.org/bugzilla/show_bug.cgi?id=3D31049 > > I don't have any objection to this as long as it's coordinated and > there's agreement from other implementors, but there *is* a way to do > it already. You posix_spawnp: > > sh -c 'ulimit -n whatever && exec "$0" "$@"' your_program args... True! Except that ulimit -n is not POSIX. There are ways around that, like making a dedicated shim binary that just does setrlimit(RLIMIT_NOFILE, make_rlimit(argv[1])); execv(argv[2], argv + 2); (or making it a special mode of your_program). But I think it would be better to have a convenient interface for it. And the double-exec() is not free either. I'm hoping if some libcs implement this, POSIX will reconsider https://www.austingroupbugs.net/view.php?id=3D603. Alternatively I suppose POSIX could standardize ulimit -n, which is already existing practice ~everywhere. > This is the general solution to doing all sorts of "child process > state setup" things that posix_spawn doesn't have a dedicated > attribute for. > > Note that for a proposal for setting rlimits via an attribute, one > complication that needs to be specified is whether the limits take > place before or after file actions, since they could change the > outcome of file actions. I'm not sure what the answer is, but just > YOLO'ing an implementation without thinking about that is a bad idea. True! Actually when I implemented my own posix_spawn()-like interface, I had setrlimit() as a file_action. Then at least the order is unambiguous. > Rich --=20 Tavian Barnes