Darren Reed wrote:
David Powell wrote:
Darren Reed wrote:
In chasing down 6271923, it appears that the culprit
is a new and seemingly arbitrary limit on the number
of contracts that a process can create. The default
would seem to be 10000.
The limit on the number of contracts has been there as long as
contracts have :)
...
e inclinued to change the way the
system ships but it would provide a proper path for someone
to set the system for the expected load/task.
Comments?
I don't see a reason why you couldn't raise the limit on the number
of contracts inetd creates in the shipping product. The point of the
control is to prevent users from denying service (contracts are cheap
to create but have a fixed namespace), not to create an employment
program for system tuners.
Ok, I'm with you on that.
The only thing I'd look out for is to make sure that if you put inetd
in a new project, that the services it starts are correctly placed
into their projects and aren't simply inheriting inetd's.
Hmm... are you implying that when inetd starts a new
service that it will not apply the method_context
properties, if set?
It should. I don't know what it does when a method_context isn't
specified, though. If it defaults to its creator's (i.e. inetd's)
project rather than being explicitly set to an absolute default, then
inetd's children would be run in the new, permissive inetd project.
Looking at the code, it appears that whether no project was specifed
or ":default" was, a child running as root always inherits the
project of the restarter. I don't know if this is intentional or
simply a naive implementation.
My temptation with inetd would be to have it take a
snapshot of which project it is in when it starts,
put it in the inetd project that has no limit on
max-contracts (or otherwise just remove that particular
resource control ?), and then place all of its children
in the project remembered from startup, unless there
is a specific project property in their context_method.
That would make sense, except that I would expect inetd to be placed
in its own project by svc.startd when it is created. i.e. it would
always be in the inetd project and not have an original project to
rememeber. I think the solution would be to have inetd default
instead to a known project, probably "system".
Another possibility would be to skip all this and just raise the
limit on the "system" project.
Dave
_______________________________________________
networking-discuss mailing list
[email protected]
