Collective resource limits status report #3
Gabor Kovesdan
gabor at FreeBSD.org
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 freebsd.org> 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:
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&fname=/SGI_Admin/IA_Resource/apa.html
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.
> http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?cmd=getdoc&coll=0650&db=man&fname=1%20jstat
> (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 FreeBSD.org .:|:. gabor at kovesdan.org
WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org
More information about the soc-status
mailing list