With this., the timeout, and all apparent issues resolved, I'm marking this case closed, approved.
Garrett D'Amore wrote: > +1 > > Darren Reed wrote: >> Updated spec below. >> >> Darren >> >> This project seeks micro/patch binding. >> >> Problem >> ======= >> The /etc/project file has been delivered (PSARC/1999/119) but its >> delivery did not define how we would add and name new projects, >> only that the numbers less than 100 were reserved. In addition, >> it did not offer full support of the features found in the project >> utilities such as prctl(1). >> >> Namespace >> ========= >> Now that the file has been shipped for a number of years, we need >> to make reasonable guesses about what customers may have done since >> its delivery. One such guess is that they may have created projects >> with names similar or the same as SMF FMRIs or executables with which >> they are associated. Thus in creating a new project to be shipped by >> default, using a name such as "login" or "init" or "inetd" cannot be >> considered to be without risk. >> >> To provide us with the required flexibility for future enginering, >> this case proposes that all project names starting with "SUNW" be >> reserved and that they are not to be used by customers to define >> their own projects. This limitation needs to be documented in >> updates to project(4) and projadd(1M). >> >> Removing Limits >> =============== >> Using prctl(1), it is possible (depending on your privileges) to >> add, change or remove resource limits associated with projects. >> When using projadd(1M), it is only possible to define projects in >> terms of new limits they will have: it is not possible to remove >> an inherited resource limit using a project definition in >> /etc/project. >> >> Thus this case would like to propose that the /etc/project file >> be extended to allow resource limits to be removed. The suggested >> syntax is to simply be '<resource_name>=removed'. As an example, >> it would be possible to use "project.max-contracts=removed". >> >> Implementation >> ============== >> This cases proposes to implement the above suggestions and to >> deliver the following changes to the existing platform. >> >> New Project >> ~~~~~~~~~~~ >> | This case will deliver a new project called "svc.inetd" that will >> be added to /etc/project. The line to be added is: >> >> | svc.inetd:5::::project.max-contracts=remove >> >> | The project name "svc.inetd" is a Project Private interface. >> >> svc:/network/inetd:default >> ~~~~~~~~~~~~~~~~~~~~~~~~~~ >> The manifest for svc:/network/inetd:default will be updated to define >> | the default inetd SMF service as a member of the svc.inetd project. >> >> Discussion >> ========== >> It is reasonable to ask the question if one daemon has a resource >> control problem, isn't it likely others will and thus isn't the >> inetd problem being solved more generic? To answer that question, >> it behooves us to recognise that inetd is a rather special daemon >> and in SMF parlance, it is also in a special cateogry - "restarter". >> >> The problem being investigated here (6271923) is particular to inetd >> in specific workload testing. Whilst we shouldn't be engineering the >> system to require tuning, removing limits for all processes removes >> the protection the limits offer, see PSARC/2004/460. In this regard, >> the best course of action is for project teams to analyse and >> understand the execution profiles that their daemons are likely to >> have and deliver special project defintions as required. >> >