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
_______________________________________________
networking-discuss mailing list
[email protected]
