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