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.
>>
>


Reply via email to