> 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 crashdump. -Steve L. > > Derek > > On Wed, May 6, 2009 at 4:08 PM, Steve Lawrence > <[1]stephen.lawre...@sun.com> wrote: > > zsched is always unkillable. *It will only exit when instructed to by > zoneadmd. > > 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 > zone_ref > 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 > attempt > killing this zoneadmd process (which lives in the global zone), and then > re-attempting "zoneadm -z <zonename> halt". > > Thanks, > > -Steve L. > > References > > Visible links > 1. mailto:stephen.lawre...@sun.com _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
