Steve Lawrence wrote:
> 
> We have a generic rctl/global-zone safety issue that needs to be addressed.
> It would seem simple enough to just make project 0 processes in the global
> zone exempt from zone rctls.  This would allow apps in the global zone to
> be capped without affecting system daemons.
> 
> The rational is that system daemons need resources or the system can become
> unusable.
> 
> The hole in this solution is that, by default, root logins join the user.root
> project.  A fix could be to make root's default project "system" instead of
> "user.root".  This would be a significant change.  Another option would be to
> document that admin's change root's default project to "system" if configuring
> rctls on the global zone.  We could even print a warning if configuring via
> zonecfg -z global.
> 
> Comments?

Steve,

making only the system project exempt from the zone rctl to ensure 
proper system operation seems reasonable to me. I am not sure about the 
'make the system project root's default project' bit. We don't do that 
for zone.max-lwps, do we?

Setting zone.max-lwps too low in the global zone will render the system 
as unusable as when setting zone.max-processes too low, yet we don't 
cater specifically for the well being of the system in the zone.max-lwps 
case, so why do it for zone.max-processes? We threaten the admin with 
fire and brimstone when he/she sets max-lwps using zonecfg, but other 
than that, we do nothing else.

Given that the intended use of zone.max-processes is mainly for 
non-global zones, I think it is reasonable to expect that the majority 
of admins won't be setting zone.* rctls on the global zone. Preventing 
those that want to from doing so by making the global zone exempt from 
the zone rctl seems overly protective. The current warning by 
zonecfg(1M) and a new stern warning in the zonecfg(1M) man page should 
suffice to make the admin aware of the dangers.

So the only thing exempt from project.max-processes and 
zone.max-processes would be processes in the system project in the 
global zone for the reason you stated. For non-global zones, the zone 
limit will be an unconditional limit (no exemption for anyone since the 
rctl is meant to protect the system and other non-global zones from a 
rogue zone).

Menno

--
Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno

_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to