I've got a zone on a Solaris 10 system which after a reboot from within the
zone has ended up in a confused state. The zone never came back up again, and
zoneadm list thinks it is down:
ID NAME STATUS PATH BRANDIP
0 global running
Martin Englund writes:
But at the same time, zoneadm boot thinks it is up:
[EMAIL PROTECTED] # zoneadm -z jcp-mail-zn-mn-colo1 boot
zoneadm: zone 'jcp-mail-zn-mn-colo1': zone is already booted
If I try to halt the zone, it just hangs:
[EMAIL PROTECTED] # zoneadm -z jcp-mail-zn-mn-colo1 halt
James,
On 9 jul 2008, at 09:32, James Carlson wrote:
Martin Englund writes:
But at the same time, zoneadm boot thinks it is up:
[EMAIL PROTECTED] # zoneadm -z jcp-mail-zn-mn-colo1 boot
zoneadm: zone 'jcp-mail-zn-mn-colo1': zone is already booted
If I try to halt the zone, it just hangs:
@opensolaris.org
__ Information from ESET NOD32 Antivirus, version of virus signature
database 3255 (20080709) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
Hi Martin,
please provide the following:
zoneadm list -cv
ps -fz jcp-mail-zn-mn-colo1
Martin Englund writes:
I get over 10,000 lines of output from ::threadlist -v any hints
on how to find the needle in the haystack? :)
I usually do ::threadlist -v ! less and then search around in the
output.
The first suspects are zoneadmd and any longish-looking stacks.
(There are more
Konstantin,
here's the info you requested:
[EMAIL PROTECTED] # pstack $(pgrep -f 'zoneadm.*jcp-mail-zn-mn-colo1')
21276: zoneadmd -z jcp-mail-zn-mn-colo1
- lwp# 1 / thread# 1
fef05405 pollsys (8046cf0, 4, 0, 0)
feeb6592 poll (8046cf0, 4, )
On 9 jul 2008, at 21:42, Konstantin Gremliza wrote:
I wrote a dtrace script to monitor zone states. The resulting
automata is in the attachment.
In the state down, we should still have a zsched (ps), but we should
not have any mounted filesystems, which is true (df).
There is no zsched