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.
Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno
zones-discuss mailing list