On 02/14/2018 05:12 PM, Tim wrote:
Allegedly, on or about 13 February 2018, Patrick O'Callaghan
sent:
> I don't know of anything that will just restore all processes that
> happened to be running when a crash occurred, or why you would even
> want that.
You'd be highly likely to get another crash, for one thing.
Back when we used a Data General mainframe, it had a feature that on an
unexpected exit, all open files got saved as "crash save" files. It
meant that you didn't corrupt the prior version of a saved file. And
it meant that you could probably recover what you were just working on.
But you had to manually figure out what all *your* crash files were.
Which is probably just as well, because the previous error that put you
in that situation, may re-occur.
Having said that, I don't get much in the way of crashes on Linux,
these days. I used to get the occasional graphics crash, but that's
not surprising considering the lack of technical support for graphics
cards by the manufacturers (their reluctance to do anything other than
build gadgets for Windows, their reluctance to supply finished product
with all the bugs ironed out, their attitude into abandoning their
never-finished products and expecting you to just buy a new one, etc).
And there'd be other (probable) hardware faults. But mains power
failure and glitches are often the most common source of stuff-ups, and
a UPS is good insurance.
"Crash" is a pretty unspecific term--certainly one that's been used for
far more than its original use (describing a head smacking into the
media on a disk drive). I'm not complaining, just making an observation.
"Crash save" files weren't unique to DG systems, BTW. DEC VAX/VMS did
it, MAI/Basic4 did it, Tandem did it...lots of systems did it (usually
using different nomenclatures). Heck, vi/vim does it in a way (via ye
ol' ".filename.swp" backup file).
Depending on the failure, often the system will save a core image file
of the process (assuming you have core dumps enabled) or stuff one into
abrt (if you have that enabled). If the program in question was compiled
with debugging enabled and the binary wasn't strip(1)ped, you can use
gdb or some other debugger to examine the core file to see WHY it died
(perhaps), but it won't reveal the environment the process was in when
it died. For example, it may have been murdered by the OOM killer and if
so, the core file won't tell you--only an examination of the system logs
would reveal that scenario.
Welcome to the world of computer forensics! Fun! (NOT!)
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- I'm telling you that the kernel is stable not because it's a -
- kernel, but because I refuse to listen to arguments like this. -
- -- Linus Torvalds -
----------------------------------------------------------------------