> I already tried killing the zoneadmd process and issuing the halt and all
> it does is start back up the zoneadmd process and hang.* I can't force a
> crashdump on the system since I can't take the box down.
> Bug 6272846 makes reference to nfs version 3, (which is the version we are
> using), and the client apparently leaking rnodes. Is there any way to
> verify this other then a forced crashdump? I might take a live core of the
> system and open a case to see if that yields anything.
The zone_ref > 1 means that something in the kernel is holding the zone.
You should be able to use "mdb -k" on the live system, and issue dcmds similar
to the comments of 6272846. No need to force a crashdump or take a live
> On Wed, May 6, 2009 at 4:08 PM, Steve Lawrence
> <stephen.lawre...@sun.com> wrote:
> zsched is always unkillable. *It will only exit when instructed to by
> Is the remaining zone "shutting down", or "down"? *(zoneadm list -v).
> What is the ref_count on the zone?
> # mdb -k
> > ::walk zone | ::print zone_t zone_name zone_ref
> If the refcount is greater than 0x1, it could be:
> * * * *6272846 User orders zone death; NFS client thumbs nose
> No workaround for this one. *A crashdump would help investigate a
> greater than 1.
> Is there a zoneadmd process for the given zone?
> # pgrep -lf zoneadmd
> If so, please provide *truss -p <pid>" of this process. *You may also
> killing this zoneadmd process (which lives in the global zone), and then
> re-attempting "zoneadm -z <zonename> halt".
> -Steve L.
> Visible links
> 1. mailto:stephen.lawre...@sun.com
zones-discuss mailing list