Xref: utzoo comp.unix.sysv386:7879 comp.unix.wizards:25458 comp.unix.internals:2721
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!sdd.hp.com!spool.mu.edu!uunet!ogicse!cvedc!mcspdx!adpplz!martin
From: martin@adpplz.UUCP (Martin Golding)
Newsgroups: comp.unix.sysv386,comp.unix.wizards,comp.unix.internals
Subject: Re: SIGPWR signal in system v
Message-ID: <724@adpplz.UUCP>
Date: 7 May 91 19:39:47 GMT
References: <1991May6.112253.5344@cs.tcd.ie> <1991May6.224407.22544@federal.uucp>
Followup-To: comp.unix.sysv386
Organization: ADP Dealer Services R&D, Portland, OR
Lines: 31

In <1991May6.224407.22544@federal.uucp> hecker@federal.uucp (Frank Hecker) writes:

>[I]f you've configured [the S2] to do a powerfail auto
>restart then (almost) all processes get sent SIGPWR.  They then get
>suspended and the contents of system memory written to disk, after
>which the system turns itself off.  When power resumes the contents of
>memory are reloaded from disk, the processes are resumed, and they're
>sent SIGPWR again.
>...you can set selected processes to not resume across a power failure 
>[they] get sent SIGTERM instead, followed by SIGKILL.

>I'm interested in hearing about any comparable implementations of
>SIGPWR on other systems.

Last time we looked, NCR and Altos had the save/resume capability,
although perhaps not as thorough as Tandem's. We've been explaining
to Motorola how easy it is, and what a good idea, but no sale yet.

Just a data point: McDonnell Douglas Reality systems have done this
for years, ever since we showed them how :-)

Another data point: I just saw a _card_ for a PC that implements the
feature: it's got on-board battery backup to hold the disk up long
enough for a memory save. I have a faint suspicion that there are some 
applications that won't come back clean.


Martin Golding    | sync, sync, sync, sank ... sunk:
Dod #0236         |  He who steals my code steals trash.
A poor old decrepit Pick programmer. Sympathize at:
{mcspdx,pdxgate}!adpplz!martin or martin@adpplz.uucp