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@xxxxxxxxxxxxxx - - 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 - ---------------------------------------------------------------------- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
