> From: "Volker A. Brandt" <v...@bb-c.de>
> Date: Mon, 12 Apr 2010 17:03:03 +0200
> To: Ben <ben.lav...@gmail.com>
> Cc: zones-discuss@opensolaris.org
> Subject: Re: [zones-discuss] Do zones add to system stability?
> > >> I'm looking to prove that by using a zone I can increase the overall
> > >> stability of a server (if the app falls over it can't the the machine 
> > >> with
> > >> it).
> > >>
> > > A kernel panic is a kernel panic is a kernel panic. :-)
> > >
> > > So if an app crashes the complete zone, chances are it will crash the
> > > entire box.  After all, it's only one Solaris kernel running.
> >
> > Out of curiosity then, how much I induce a kernel panic?
> A good question.  I haven't actively tried to induce a kernel panic
> for many years, so I'd suggest asking the experts in the osol-discuss
> or osol-code mailing lists.
> Also, there's a program out there called "crashme" that tries to crash
> a system by throwing random input at it:
> http://crashme.codeplex.com/Wikipage


Used my "google foo" on "induce solaris kernel panic" and right near
the top was a pointer to docs.sun.com discussing "Kernel Destructive
Action" that contained this tidbit at this URL:



void panic(void)

The panic() action causes a kernel panic when triggered. This action
should be used to force a system crash dump at a time of interest. You
can use this action together with ring buffering and postmortem
analysis to understand a problem. For more information, see Chapter 11,
Buffers and Buffering and Chapter 37, Postmortem Tracing respectively.
When the panic action is used, a panic message appears that denotes the
probe causing the panic. For example:

  panic[cpu0]/thread=30001830b80: dtrace: panic action at probe
  syscall::mmap:entry (ecb 300000acfc8)

  000002a10050b840 dtrace:dtrace_probe+518 (fffe, 0, 1830f88, 1830f88,
    30002fb8040, 300000acfc8)
    %l0-3: 0000000000000000 00000300030e4d80 0000030003418000 00000300018c0800
    %l4-7: 000002a10050b980 0000000000000500 0000000000000000 0000000000000502
  000002a10050ba30 genunix:dtrace_systrace_syscall32+44 (0, 2000, 5,
    80000002, 3, 1898400)
    %l0-3: 00000300030de730 0000000002200008 00000000000000e0 000000000184d928
    %l4-7: 00000300030de000 0000000000000730 0000000000000073 0000000000000010

  syncing file systems... 2 done
  dumping to /dev/dsk/c0t0d0s1, offset 214827008, content: kernel
  100% done: 11837 pages dumped, compression ratio 4.66, dump
So using dtrace and panic() might do the trick...

Gregory Hicks

> Hope this helps -- Volker
> -- 
> ------------------------------------------------------------------------
> Volker A. Brandt                  Consulting and Support for Sun Solaris
> Brandt & Brandt Computer GmbH                   WWW: http://www.bb-c.de/
> Am Wiesenpfad 6, 53340 Meckenheim                     Email: v...@bb-c.de
> Handelsregister: Amtsgericht Bonn, HRB 10513              Schuhgröße: 45
> Geschäftsführer: Rainer J. H. Brandt und Volker A. Brandt
> _______________________________________________
> zones-discuss mailing list
> zones-discuss@opensolaris.org

Gregory Hicks                           | Principal Systems Engineer
                                        | Direct:   408.569.7928

People sleep peaceably in their beds at night only because rough men
stand ready to do violence on their behalf -- George Orwell

The price of freedom is eternal vigilance.  -- Thomas Jefferson

"The best we can hope for concerning the people at large is that they
be properly armed." --Alexander Hamilton

zones-discuss mailing list

Reply via email to