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
