On Wed, Dec 03, 2008 at 02:09:12PM +0100, Sico Bruins wrote:
> On Wed, Dec 03, 2008 at 12:42:42PM +0100, Otto Moerbeek wrote:
>
> > On Wed, Dec 03, 2008 at 12:36:49PM +0100, Sico Bruins wrote:
> >
> >> On Wed, Dec 03, 2008 at 12:06:14PM +0100, Otto Moerbeek wrote:
> >>
> >>> On Wed, Dec 03, 2008 at 11:57:32AM +0100, Sico Bruins wrote:
> >>>
> >>>> On one of my PCs I ran into the process table full / cannot fork
> >>>> trouble, so I decided to make a single change in the GENERIC
> >>>> kernel config: I bumped up the maxusers setting to 128.
> >>>>
> >>>> Config warned me that "config: warning: maxusers (128) > 100".
>
> [stuff deleted for brevity]
>
> >> Since I am in group staff, and maxproc-cur in login.conf for staff is
> >> 128, that can't be it. kern.maxproc is over 2,000.
> >
> > You are confusing groups and login classes.
>
> You have a point there, however it does not explain the problem. After
> I do ulimit -p unlimited, ulimit -a tells me I should be able to have
> 128 processes (maxproc-max for the default login class). Yet the
> system-wide process table fills up at 100.
How do you know the system wide process table fills up? You are
misinterpreting things.
Changing ulimit settings via the command line only applies to the
current shell and its future children.
>
> > -Otto
>
> Anyway, thanks to all for the rapid feedback on this list. I'm inspired
> to do some more research on login classes, if only to satisfy my own
> curiousity.
Just change you login class to staff and check it with userinfo(8).
-Otto
