OpenSolaris

adding rctls on proj 0's etc project line does not put any rctls on the
system processes.  These rctls are only applied when someone enters the
system process vi login or newtask.

Create a new service that simply calls `newtask -p system /usr/bin/true` as a start method.

See attached IDR_projects.xml
What seems to be the best workaround consist of setting the resource control for the system project via the /etc/system file, as shown in the following table:

+-----------------------------+----------------------------------------+
| Resource Control            | /etc/system entry                      |
+=============================+========================================+
| process.max-file-descriptor | set rlim_fd_cur =  <value>             |
|                             | set rlim_fd_max =  <value>             |
+-----------------------------+----------------------------------------|
| project.max-shm-memory      | set shmsys:shminfo_shmmni = <value>    |
|   (multiplied values)       | set shmsys:shminfo_shmmax = <vaule>    |
+-----------------------------+----------------------------------------|
| project.max-shm-ids         | set shmsys:shminfo_shmmni = <value>    |
+-----------------------------+----------------------------------------|
| project.max-msg-ids         | set msgsys:msginfo_msgmni = <value>    |
+-----------------------------+----------------------------------------|
| project.max-sem-ids         | set semsys:seminfo_semmni = <value>    |
+-----------------------------+----------------------------------------+

All the above are documented in the "Solaris Tunable Parameters Reference Manual", available at http://docs.sun.com/app/docs/doc/817-0404.  These parameters are listed as being obsolete, however they do still work, and do offer an acceptable zero risk solution to this particular issue.
There are several ways to work-around this specific project 0 issue (tested in Lab with S10):

1/ Setting the values in /etc/system (as explained above)
--> It will set the default values of the parameters for all the projects on the machine (including project 0 "system").


2/ Use an explicit call to "newtask -p <project> Command" to run the start (and maybe also the stop) method.
--> If a start method wants to make sure the processes will start with the appropriate parameters of a specific project described in a local (/etc/project) or remote repository (project table), then the use of the "newtask -p <projectName>" to prefix the SMF method should guaranty the use of the appropriate project


3/ Use of the "project" SMF method_context attribute:
--> As it is explained in the DTD file (/usr/share/lib/xml/dtd/service_bundle.dtd.1)

        project The project ID, in numeric or text form.  ":default" can
                be used as a token to indicate use of the project
                identified by getdefaultproj(3PROJECT) for the non-root
                user specified by the credential or profile specified.
                If the user is root, ":default" designates the project
                the restarter is running in.

    Because of the Bug 6411391 [Empty method_context's don't work], selecting a specific project for a root user from SMF, requires the addition of a method_profile or method_credential element. In other words, to select a specific project for the default (root) user for an SMF service, you should for example explicitly identify the user in the associated method:

        <exec_method
                type='method'
                name='start'
                exec='/path/to/my/start_method'
                timeout_seconds='60'>

                <method_context project='system'>   <!-- Any other project name could be used for this root user. -->
                        <method_credential user='root' />
                </method_context>

        </exec_method>



4/ As a last resort, we can also use a service like the one described in attachment of this CR (calling a "newtask -p system /usr/bin/true" in the start method -- file IDR-projects.xml.zip) that needs to be started before the service that is supposed to get some specific "system" project parameters.


General conclusion:
===================
Even if this peculiarity of project "system" was corrected, whether in a future Solaris release or in Solaris 10, best practice would still be for anything and everything that requires tuning via project attributes to be placed into a project of its own, and to do this via smf_method(5) contexts wherever feasible.

Let's put the emphasis on the fact that the "system" project is the default for all services on the machine. So it should be considered as catch-all for everything that gets run out of the box and that _doesn't_ require any tuning of the out-of-the-box default settings.
That's the reason why even a system service needing some resources tuning should be run in a separate project.

N/A