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
zones-discuss@opensolaris.org

Reply via email to