Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!mcnc!rti!xyzzy!meissner From: meissner@xyzzy.UUCP (Michael Meissner) Newsgroups: comp.unix.questions,comp.unix.wizards Subject: Re: core dumps life-after-death Message-ID: <137@xyzzy.UUCP> Date: Thu, 16-Jul-87 10:16:30 EDT Article-I.D.: xyzzy.137 Posted: Thu Jul 16 10:16:30 1987 Date-Received: Sat, 18-Jul-87 07:12:56 EDT References: <276@frc.UUCP> Reply-To: meissner@nightmare.UUCP (Michael Meissner) Distribution: comp Organization: Data General (Languages @ Research Triangle Park, NC.) Lines: 29 Xref: mnetor comp.unix.questions:3217 comp.unix.wizards:3267 From article <276@frc.UUCP>: > /* stuff about using dbx on core dumps */ > I imagine there are problems with open files, > file positions, and other "kernel" type information. > Can a process get all this "stuff" as it dies. And > do the tools to recreate the "old" environment already > exist? > > Can core Images be used to checkpoint large jobs? In short this is not a good idea. If you were to include "ALL" of the information about the process state, it would envitably have to include the effective user-ID and group-ID of the process. If this were included in the file, users could then get around what protections UNIX does offer by checkpointing a job, and then using something like adb to change the user/group to some other user. I remember when I was an undergrad at the University of Minnesota ten years ago, that the operations staff removed the checkpoint facility from the CDC 6400 because of this problem. Even if it were possible to make such a system secure, there are still many loose ends. For example if you restore a process, do you have to repaint the screen at the time of the dump, open up socket connections to servers (which might not have the same process ID), and in fact restart the server with the same state. Ditto for pipes, terminal controls, etc. If you really need to checkpoint large jobs, I would suggest that it be up to the application. Bare in mind, that attempts to unexec a process like GNU does, quickly becomes implementation dependent (ie, non-portable). -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner