I don't believe that I can see the comments since they are not public.
Is that something you can pass along?
On Wed, May 6, 2009 at 5:27 PM, Steve Lawrence <stephen.lawre...@sun.com>wrote:
> > I already tried killing the zoneadmd process and issuing the halt and
> > it does is start back up the zoneadmd process and hang.* I can't force
> > 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
> > 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
> > 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
> to the comments of 6272846. No need to force a crashdump or take a live
> -Steve L.
> > Derek
> > 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
> > zoneadmd.
> > Is the remaining zone "shutting down", or "down"? *(zoneadm list
> > 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
> > attempt
> > killing this zoneadmd process (which lives in the global zone), and
> > re-attempting "zoneadm -z <zonename> halt".
> > Thanks,
> > -Steve L.
> > References
> > Visible links
> > 1. mailto:stephen.lawre...@sun.com
zones-discuss mailing list