Menno Lageman wrote:

Nobody gets signaled, as 'signal' (and 'deny' for that matter) are not valid actions for zone.cpu-shares. This is because cpu-shares is not a limit that can be exceeded in the sense that for instance project.max-filedescriptor can be exceeded. Once a zone is at it's maximum allowed cpu share, it won't get scheduled so it can't exceed the limit.


If you want to know what actions are possible for a rctl, see the rctladm(1M) output:

# rctladm zone.cpu-shares
zone.cpu-shares syslog=n/a [ no-basic no-deny no-signal no-syslog count ]

'no-deny' tells you that 'deny' is not a valid action for this rctl. Ditto for 'no-signal' and 'no-syslog'.

Great!  Thank you for clearing that up.  Same question, for zone.max-lwps.

# rctladm zone.max-lwps
zone.max-lwps               syslog=off     [ no-basic count ]

I guess, then, I can have action=signal=TERM? Who gets signaled, the process that wants another lwp, or zoneadmd, or something else? Not that I want to kill that process, I just want to know the mechanism. 'deny' would make more sense here? What would 'none' do, nothing, nullifying the limit?

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

Reply via email to