David Powell wrote: > Darren Reed wrote: >> David Powell wrote: >>> ... >>> 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.
That's very tempting because it's an even smaller change... but whether it should be done by editting /etc/project or $SRC/uts/common/os/project.c? One might even argue that the limit should simply be removed for the simple reason that there isn't a limit on taskid's. What do we gain by having a low limit on contracts but not on taskid's or lwp's? But there's something else I like about putting inetd in its own project and shipping that: it gives Solaris a working, shipping, example of the FAQ questions in the SMF FAQ that cover this topic. So in addition to saying "here's how to do X", we can also say "see inetd as a working example of how this is done." That's not a reason, by itself, to do it. Darren
