I've done some more archaeology on this topic, reviewing the notes in PSARC/2003/193 and PSARC/2004/460. It would seem like there are competing problems here: the desire for the system to not require it to be tuned for specific performance goals but also to protect it from denial of service attacks or just problematic behaviour where contacts are created endlessly and never cleaned up in a timely fashion.
With that in mind, I can't see how changing the system project to have either unlimited or a large number of contracts could be considered the correct thing to do as it is in only very specific circumstances that any change from the default is required. Restarters are something of a special process under SMF and thus I can only suggest that developers of them consider the anticipated use of them and supply project definitions specific to them if their behaviour needs to be outside of the normal scope (as is here.) Which is to say that I'm not in favour of creating a restarter project, or similar, and placing inetd under that as it assumes other restarters will have the same requirements - an assumption I've no right in making. Thus I'm quite comfortable that the change posted and reviewed is correct (but needs some additional commenting.) There is one small piece of advice that comes from looking into this and that is it should be possible to install a new project when a new package is installed. Otherwise, I can't see how it will be possible to automatically update /etc/project to match a new project that's referenced from the SMF manifest. For us, it's not such a big deal, but for 3rd parties, it could be interesting delivering a new ips pkg that delivers an SMF profile referring to a new project that is not defined when the pkg command is first run... Darren
