From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
To: cygwin@cygwin.com
Subject: Re: setrlimit always fails
Date: Fri, 12 Feb 2021 11:56:12 -0700 [thread overview]
Message-ID: <5dc9c6fa-dee6-94a1-e3ee-e73eb6096047@SystematicSw.ab.ca> (raw)
In-Reply-To: <20210212091233.GG4251@calimero.vinschen.de>
On 2021-02-12 02:12, Corinna Vinschen via Cygwin wrote:
> On Feb 12 00:26, Brian Inglis wrote:
>> On 2021-02-11 19:06, Ken Brown via Cygwin wrote:
>>> On 2/11/2021 10:23 AM, Patrick Chkoreff wrote:
>>>> I'm trying to use setrlimit to impose limits on various resources such
>>>> as CPU time and memory. The call to setrlimit always fails. I've
>>>> distilled this into the following example test.c:
>>> [...]
>>>> if (setrlimit(RLIMIT_CPU,&rlim) < 0)
>>> [...]
>>>> setrlimit: Invalid argument
>>>
>>> Cygwin's setrlimit only supports a few resources, as you can see in the source:
>>>
>>> https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/resource.cc;h=97777e9d223466b7635b990d6c9e0bfb9e2e9a46;hb=HEAD#l201
>>
>> In that case could I suggest:
>>
>> /usr/share/doc/cygwin-doc/html/cygwin-api/compatibility.html#std-susv4
>> https://cygwin.com/cygwin-api/compatibility.html#std-susv4
>>
>> in https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/doc/posix.xml
>>
>> get/setrlimit entries should be annotated with:
>
> https://cygwin.com/acronyms/#PGA
I'll see what I can do. Does anyone know if <ulink> is supported within
<screen>? I seem to remember struggles updating proc(5) in specialnames.xml.
It appears that code using other than the common POSIX resources need existence
checks.
I am unsure if it is worth adding definitions for any others.
It may be possible to implement RSS, NPROC, LOCKS, NICE, but
https://cygwin.com/acronyms/#SHDTI
Comparing Cygwin and Linux ([uapi/]asm-generic/}:
#define RLIMIT_CPU 0 /* CPU time in seconds */
#define RLIMIT_FSIZE 1 /* Maximum filesize */
#define RLIMIT_DATA 2 /* max data size */
#define RLIMIT_STACK 3 /* max stack size */
#define RLIMIT_CORE 4 /* max core file size */
#ifdef LINUX
#define RLIMIT_RSS 5 /* max resident set size */
#define RLIMIT_NPROC 6 /* max number of processes */
#define RLIMIT_NOFILE 7 /* max number of open files */
#define RLIMIT_AS 9 /* address space limit */
#else
#define RLIMIT_NOFILE 5 /* max number of open files */
#define RLIMIT_OFILE RLIMIT_NOFILE /* BSD name */
#define RLIMIT_AS 6 /* address space limit */
#endif
#ifdef LINUX
#define RLIMIT_LOCKS 10 /* maximum file locks held */
#define RLIMIT_SIGPENDING 11 /* max number of pending signals */
#define RLIMIT_MSGQUEUE 12 /* maximum bytes in POSIX mqueues */
#define RLIMIT_NICE 13 /* max nice prio allowed to raise to */
#define RLIMIT_RTPRIO 14 /* maximum realtime priority */
#define RLIMIT_RTTIME 15 /* timeout for RT tasks in us */
#define RLIM_NLIMITS 16
#else
#define RLIMIT_NLIMITS 7 /* upper bound of RLIMIT_* defines */
#endif
Linux man says:
"RLIMIT_MEMLOCK and RLIMIT_NPROC derive from BSD and are not specified in
POSIX.1; they are present on the BSDs and Linux, but on few other implementations.
RLIMIT_RSS derives from BSD and is not specified in POSIX.1; it is nevertheless
present on most implementations.
RLIMIT_MSGQUEUE, RLIMIT_NICE, RLIMIT_RTPRIO, RLIMIT_RTTIME, and
RLIMIT_SIGPENDING are Linux-specific."
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
next prev parent reply other threads:[~2021-02-12 18:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-11 15:23 Patrick Chkoreff
2021-02-12 2:06 ` Ken Brown
2021-02-12 7:26 ` Brian Inglis
2021-02-12 9:12 ` Corinna Vinschen
2021-02-12 18:56 ` Brian Inglis [this message]
2021-02-12 20:38 ` Brian Inglis
2021-02-12 15:11 ` Patrick Chkoreff
2021-02-15 9:14 ` Corinna Vinschen
2021-02-15 19:54 ` Patrick Chkoreff
2021-02-15 20:48 ` Corinna Vinschen
2021-02-16 14:53 ` Patrick Chkoreff
2021-02-16 15:22 ` Marco Atzeri
2021-02-16 18:33 ` Brian Inglis
2021-02-12 9:11 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5dc9c6fa-dee6-94a1-e3ee-e73eb6096047@SystematicSw.ab.ca \
--to=brian.inglis@systematicsw.ab.ca \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).