One of the items listed as 'future work' is the zone.max-processes resource control to limit the number of process slots a zone may have.
I have prototyped this and would like to solicit feedback. The goal of the zone.max-processes resource control is to protect the global zone and other non-global zones from a non-global zone that uses an inordinate amount of process slots (either by accident or by malice such as a fork bomb). While some protection against this can be achieved with the zone.max-lwps resource control and/or memory capping, it is not an ideal solution. The zone.max-lwps rctl cannot prevent zombies from filling up process slots for instance, as a zombie (by definition) does not have any lwps. The prototype has a per zone limit on the number of slots that can be used by the zone at any given time. The limit is enforced regardless of the user that tries to get a process slot, i.e. the root user is not special in any way. Since we're trying to protect others from a misbehaving zone, allowing root to escape the limit would render the rctl useless. This can lead to a failure mode where the zone itself may not be able recover by itself. The zone.max-lwps rctl has the same failure mode, and given the goal of protecting the rest of the system, that seems acceptable. For compatibility with the current behavior the zone.max-processes rctl will only have an unlimited 'system' limit by default. To limit the number of slots for a zone the administrator must add a 'privileged' limit with the appropriate number of processes required. zonecfg(1M) has been extended to support setting this limit using the short form 'set max-processes=nnn' or the classic 'add rctl ...' form. A lower bound for the number of processes (currently an arbitrary 100) is enforced by zonecfg to prevent the administrator from making the zone unbootable. The usual checks done at process creation (against v_maxup etc.) are still done, but after the zone.max-processes check. The default configuration will be equivalent to the current behavior. The prototype currently only enforces the limit for non-global zones to prevent rendering the system unusable by setting too low a limit on the global zone. This adds a safety net, but may also add some confusion as the limit on the global zone can be set but is not enforced (in the same way that system processes are exempt fro rctls), so this may or may not be a good option. Thoughts? Menno -- Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno _______________________________________________ zones-discuss mailing list email@example.com