The zone is in a shutting_down state.

The mdb command for this zone returns 0x1a, greater then 1.

zone_name = 0xfffffe86c83d61c0 "zonetest-new"
zone_ref = 0x1a

This is new to me, what is the refcount counting? What should this value be
for the zone to shutdown?

There is a zoneadmd processes running for the zone.  Trussing it and issuing
the halt command I can see it look up the zone, get some attributes and then
send it the shutdown which is where it hangs.

5364:   psargs: zoneadmd -z zonetest-new
5364/2:         door_return(0xFE6CD870, 4096, 0x00000000, 0) (sleeping...)
5364/4:         door_return(0x00000000, 0, 0x00000000, 0) (sleeping...)
5364/3:         door_unref()                    (sleeping...)
5364/1:         pollsys(0x08046C50, 4, 0x00000000, 0x00000000) (sleeping...)
5364/2:         32.4128 door_return(0xFE6CD870, 4096, 0x00000000, 0)    = 0
5364/2:         32.4642 door_ucred(0x08077150)                          = 0
5364/2:         32.4769 zone_lookup("zonetest-new")                      =
5364/2:         32.4770 zone_getattr(64, ZONE_ATTR_STATUS, 0xFE6CD85C, 4) =
5364/2:         32.4843 zone_lookup("zonetest-new")                      =
5364/2:         zone_shutdown(64)               (sleeping...)

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.


On Wed, May 6, 2009 at 4:08 PM, Steve Lawrence <>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.
zones-discuss mailing list

Reply via email to