Date: Thu, 24 Jun 2010 09:32:27 +0200 From: Gabor Kovesdan <gabor@FreeBSD.org> To: pluknet <pluknet@gmail.com> Cc: soc-status@freebsd.org Subject: Re: Collective resource limits status report #3 Message-ID: <4C230A0B.3080700@FreeBSD.org> In-Reply-To: <AANLkTikLoskpABjaUlufnBGOBeU-Z62CiuQfH5sDyY1Z@mail.gmail.com> References: <4C1BCB96.4040608@FreeBSD.org> <AANLkTikwUYWCIvlDQ60L4L8gMcEeDFIV6850csEwuH8E@mail.gmail.com> <4C21CAF0.2040607@FreeBSD.org> <AANLkTikLoskpABjaUlufnBGOBeU-Z62CiuQfH5sDyY1Z@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
El 2010. 06. 23. 14:44, pluknet escribió: > On 23 June 2010 12:50, Gabor Kovesdan<gabor@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@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C230A0B.3080700>