Collective resource limits status report #3

Gabor Kovesdan gabor at
Thu Jun 24 07:32:38 UTC 2010

El 2010. 06. 23. 14:44, pluknet escribió:
> On 23 June 2010 12:50, Gabor Kovesdan<gabor at>  wrote:
>>> +typedef __uint32_t     __jid_t;
>> This has to be signed because calls may return -1.
> It might return jid_t (-1) then as it's done similarly for getpid(2) family
> which return pid_t(-1) on error, or similarly for inet_addr(3) which returns
> INADDR_NONE (0xffffffff, or -1 for uint32_t, let it be signed) on error.
In the meantime, I've found this:
Now, I changed it back because some applications may expect it to be a 
64-bit variable then, and we are not sure about its relation to uid_t 
yet, so we may provide higher capacity.
>>> +#define        JLIM_NLIMITS    8
>>> +
>>> +/*
>>> + * Job limit string identifiers
>>> + */
>>> +
>>> +#ifdef _JLIMIT_IDENT
>>> +static char *jlimit_ident[JLIM_NLIMITS] = {
>>> +       "cputime",
>>> +       "datasize",
>>> +       "files",
>>> +       "processes",
>>> +       "threads",
>>> +       "vmemory",
>>> +       "physmem",
>>> +       "ressetsize",
>>> +};
>>> +#endif
> This is modeled by me after IRIX'ish jstat(1) manpage.
> I'm still unsure, so it's up to you if it worth to be there.
> (though I'm afraid it may be a bit obsolete).
Oh, thanks, it makes sense. I haven't looked so far yet, just read the 
syscall manpages, not the utilities.
>> A quick look at the limit manipulation syscalls doesn't suggest that we need
>> these. I see you did it in a consistent way with rlimits but why to have
>> those if they aren't really necessary. Or are they?
>>> @@ -97,6 +102,8 @@
>>>          long    ui_ptscnt;              /* (b) number of pseudo-terminals
>>> */
>>>          uid_t   ui_uid;                 /* (a) uid */
>>>          u_int   ui_ref;                 /* (b) reference count */
>>> +       jid_t   ui_jid;                 /* (c) job in which this uid_t
>>> lives */
>>> +       struct ulimit *ui_limit;
>>>   };
>> Unfortunately, IRIX is not the most well-documented operating system, so I
>> still have some doubts on the actual behavior but I don't think a user lives
>> in a job or does it? It's true that makenewjob() takes an uid_t argument but
>> I think that will be a credential info for the created job, however I
>> haven't been able to figure yet where it is used. What I am quite sure about
>> is that job is an unescapable container and you can create a job with
>> makenewjob(), which doesn't only create the job but associates the caller
>> process to the job and then forked processes will also live in the same job.
>> Please correct me if I am wrong. I've asked in the list if someone could
>> provide me access to an IRIX machine but no answer yet...
> I'd say some part (none, some processes, or all of them) of that (and only
> that) user lives in a job.
> Yeah, IRIX documentation has a bit of uncertainty for me as well.
> They wrote: "With the IRIX kernel job limits feature, all processes
> associated with a particular login session or batch submission are
> encapsulated as a single logical unit called a job. The job is the
> container used to group processes by login session."
I think it only applies if you start your shell in a job. Then the shell 
forks the processes that you execute and it will then automatically 
assigned to the same job.
> But next: "Limits on resource usage are applied on a per user basis for a
> particular job".
Yes, this is confusing because you cannot directly add processes to a 
job, so if user A creates a job, user B cannot really access it. Maybe 
it refers to setuid processes? If they act as root, may they exceed the 
limits set by the user?
> "Job limits software helps ensure that each user has access to the
> appropriate amount of system resources such as CPU time and memory
> and makes sure that users do not exceed their allotted amount."
I think this is just the use case not a direct description of the 
behavior. The administrator may want to start user shells in a specific 
job, by default, which actually can achieve this kind of control.
> Btw, it's interesting how to properly make getjusage(2), if a process
> running inside a job wants to change it's uid/gid
> (if basing on the claim that a job scope is limited by per-user basis).
Yes, this is an open question still.

Gabor Kovesdan
FreeBSD Volunteer

EMAIL: gabor at .:|:. gabor at
WEB: .:|:.

More information about the soc-status mailing list