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.
