Repost/Semi-Summary: How to keep a paniced SPARC machine from rebooting

Hi all

OK, within a couple of hours, I received half a gzillion replies about
auto-boot?=false, plus a single suggestion that I didn't waste people's
valuable time with such obvious novice questions, so I realized that I did not
make my point clear:
  These machines are *supposed* to auto-boot - in fact they are console-less
during normal operation (don't ask), so requiring a manual boot is out of the
question; they are also shut down by the application when it closes down.
  AFAIK, setting auto-boot?=false on ANY OBP-based system will prevent it from
auto-booting at all, including at power-on.  What I am after is a way to make
the system "halt" instead of "reboot" on panic (the "halt" and "reboot"
commands know how so there must be a way...), so that it stays down until the
next power cycle.

Apart from the numerous auto-boot? responses, there were a few others:
  Jim Holland suggested setting watchdog-reset?=false; that was my own first
impulse, but it didn't do the trick (may work on other HW/OPB versions).
  David Deaves suggested setting error-reset-recovery to "sync" or "none".
Unfortunately, the OPB on my board does not have this variable (sigh...)
  Reggie Beavers provided the following which I will look into:
        "Alternatively, you could use a cluster to manage your
      environment. Check out http://www.fstha.com. It's free
      and works, supporting disksutie with and without
      desksets as well as vxvm."

Thanks 1M so far - updated summary follows (I hope)

/Carsten

----- Original Message -----
From: "Carsten Knudsen" <case139@email.com>
To: sunmanagers@sunmanagers.org
Subject: How to keep a paniced SPARC machine from rebooting
Date: Sun, 26 Jun 2005 22:25:23 +0100

>
> Hi list-eners (!)
>
> Setup brief: Two SPARC machines (Force, not Sun, but that's probably the
same
> for the sake of this discussion) running our customer's app in a
> primary/backup configuration with a shared couple of SCSI disks accessed as
a
> DiskSuite disk set.
>    If the primary server announces that it is for some reason not able to
> continue, the backup server forcibly takes over the disk set, causing the
> primary to panic (standard disksuite behaviour), but when it comes up
again,
> it appears to mess up the SCSI communication between the shared disks and
the
> now-primary server, which in turn causes the entire application to fail.
>    We can live with the failed server not coming back to life again on its
own,
> but I cannot find a way to keep it from trying...  Any good suggestions??
> And... for various reasons (space constraints, a.o.), putting in an extra
SCSI
> box such as an S1 is not an option.
>
> TIA/IWS
>
> /Carsten
>
>
> --
> ___________________________________________________________
> Sign-up for Ads Free at Mail.com
> http://promo.mail.com/adsfreejump.htm
> _______________________________________________
> sunmanagers mailing list
> sunmanagers@sunmanagers.org
> http://www.sunmanagers.org/mailman/listinfo/sunmanagers


--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers