(Note: there are two different senses of "global" here, so I'm sorry if this
will be hard to follow)

Can one have global core dumps in the global zone without also having the
global zone get global core dumps of non-global zone processes?

Typically folks might just put all core dumps in one place, since they
rarely get looked at anyway; that way it's easier to clean them out
after some number of days.  That might be as true for the global
zone as for the non-global zones, given that even Sun, Veritas, and
other system-level software vendor applications can occasionally
core dump.

I know one can have non-global zones generate their own global core
dumps (which have nothing to do with the global zone as such).  But I'd
like global core dumps of global-zone associated processes _only_ to be
possible in the global zone.

That's not just a matter of taste issue.  Consider this:  one might ideally
have a system with nothing but OS and system administration related
processing taking place in the global zone, and one or more non-global
zones encapsulating various applications.  If core dumps in non-global
zones can fill up for example /var in the global zone, that's just about
a denial of service, since if /var fills up, it may not be possible to log in,
requiring a reboot of the global zone and thus of the system, perhaps
even a dirty (break-sync) reboot.  Even if one could halt the non-global
zones cleanly first, that's still quite disruptive, and I think it should be
possible to prevent anything in a non-global zone from causing such a
denial of service, while still being able to have global zone only global
core dumps in the global zone (if you follow that last bit...).

Anyway, I don't see how to do that, or if it could be done with existing
facilities.  I'd love it if there were a way to specify rules
in terms of the various %letter keys in the coreadm man page for when
a core dump should or shouldn't be produced.
 
 
This message posted from opensolaris.org
_______________________________________________
opensolaris-help mailing list
[email protected]

Reply via email to