>    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

-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

Reply via email to