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
