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. On Tue, May 05, 2009 at 10:18:07AM -0500, Derek McEachern wrote: > Just follow up on the progress and resolution to my stuck zones problem.* > I had two zones stuck in the shutting_down state. > > Based on initial feedback I looked for nfs mounts in /etc/mnttab in the gz > that were mounted in the ngz. There were a couple and umount'ed them. Then > I was able to find two processes that indicated they were accessing the > ngz filesystem, zsched and svc.configd. I tried trussing svc.configd but > was unable to due to "unanticipated system error".* I killed svc.configd, > ran the zoneadm halt and the zone successfully shut down. > > On the second zone that's stuck I umount'ed the nfs file systems and > checked for processes accessing the ngz filesystem and the only one > reported is zsched. Trying to halt the zone doesn't do anything and from > the looks of it zsched appears to be unkillable. It looks like this zone > is here to stay until I can reboot the box. > > Derek > > On Tue, Apr 28, 2009 at 10:09 PM, Derek McEachern > <derekmceach...@gmail.com> wrote: > > There were a bunch of nfs mounts listed in the /etc/mntab of the global > zone. I was able to umount them but zone is still hung up. > > *I tried killing the zoneadmd process and ran zoneadm halt again and it > started the zoneadmd back up but it didn't do anything. > > Thanks to everyone for their suggestions, looks like I'm going to have > to wait until I can take the box down for a reboot. > > Regards, > Derek > > On Tue, Apr 28, 2009 at 9:02 PM, Alexander J. Maidak > <ajmai...@mchsi.com> wrote: > > If its hung nfs mount you should be able to see it still mounted in > the /etc/mntab file in the global zone: grep nfs /etc/mntab. It will > be > mounted under the zonepath. *You should then be able to do a umount > -f /<path-to-nfsmnt> from the global zone and if you're really lucky > the > zone will finish shutting down. > > -Alex > On Tue, 2009-04-28 at 16:19 -0500, Derek McEachern wrote: > > It's possible that it could be nfs mount related since the zone did > > have nfs mounted fs's but they should have been umounted prior to > > shutting down the zone. *In any event I can no longer get into the > > zone to checkusing *zlogin and zlogin -C. > > > > I tried Bryan's suggestion on looking for processes that might have > > open filehandles to files under the zone's filesystem tree but I > don't > > see that there are any. > > > > On Tue, Apr 28, 2009 at 3:40 PM, Bryan Allen > <...@mirrorshades.net> > > wrote: > > * * * * > > +------------------------------------------------------------------------------ > > * * * * | On 2009-04-28 15:37:22, Derek McEachern wrote: > > * * * * | > > * * * * | We were trying to bring down a zone on a S10 U4 system and > > * * * * it ended up stuck > > * * * * | in the shutting_down state. > > * * * * | > > * * * * | ID NAME * * * * * * STATUS * * PATH > > * * * * BRAND * *IP > > * * * * | 74 zonetest-new * * shutting_down /zone/zonetest-new > > * * * * native > > * * * * | shared > > * * * * | > > * * * * | > > * * * * | The only process I see running is the zoneadmd process > > * * * * | > > * * * * | dlet15:/home/derekm/ ps -efZ | grep zonetest-new > > * * * * | * global * *root 12680 * * 1 * 0 * Apr 24 ? * * * * * 0:02 > > * * * * zoneadmd -z > > * * * * | zonetest-new > > > > > > > > * * * * Do any processes (notably shells in the global zones) have > an > > * * * * open filehandle > > * * * * somewhere under the zone's filesystem tree? This can (at > least > > * * * * on Sol10) cause > > * * * * zones to not shut down, since it can't close the FH (I > assume, > > * * * * anyway). > > * * * * -- > > * * * * bda > > * * * * cyberpunk is dead. long live cyberpunk. > > * * * * _______________________________________________ > > * * * * zones-discuss mailing list > > * * * * zones-disc...@opensolaris.org > > > > _______________________________________________ > > zones-discuss mailing list > > zones-disc...@opensolaris.org > > References > > Visible links > 1. mailto:derekmceach...@gmail.com > 2. mailto:ajmai...@mchsi.com > 3. mailto:b...@mirrorshades.net > 4. mailto:firstname.lastname@example.org > 5. mailto:email@example.com > _______________________________________________ > zones-discuss mailing list > firstname.lastname@example.org _______________________________________________ zones-discuss mailing list email@example.com