ncd@frc.UUCP (the nemesis) (07/05/87)
Ive found the that dbx utility great for examining core dumps, ideal for finding importabilities in portable ported code. What/why are the restriction on restarting the coreimage as a process? 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 a similiar blood vessel, On our Pyrimad (sysV+4.2BSD) we have a selection of signals, ie ... HUP INT QUIT ILL TRAP IOT EMT FPE KILL BUS SEGV SYS PIPE ALRM TERM STOP TSTP CONT CHLD TTIN TTOU TINT XCPU XFSZ However on microport(sysV) many of these dont exist. The ones Id like are TSTP STOP CONT. How do you "stop"/suspend a process in sysV?. And finally, how does one find out about "the kernal" without having a source license? Are there any good books that I should be ordering? The kind of books that out line how to get the best out of unix, and tricks of the trade etc... Ive seen some good ones, like Advanced Unix Programming (Marc J. Rochkind) (great book!) The Minix book was great also, but its not Unix. Just thought Id ask... Neville BTW. If only(and any) of the big boys can afford to have a Unix source license, I cannot see the logic in making the source so sacred. It just means that the little (and interested) guys go without and have to wait for their hardware suppliers to patch found(and annoying) bugs. What "could" be happening is the suppliers consider the "temporary fixes" to be their "property" (gives them a competitive edge and all that). And thus the users suffer. Ive heard of cases (elsewhere) that this is concidered the case. PERHAPS the answer is only big boys are worth suing.... WTB.
francus@cheshire.columbia.edu.UUCP (07/07/87)
> In a similiar blood vessel, On our Pyrimad (sysV+4.2BSD) >we have a selection of signals, ie ... >HUP INT QUIT ILL TRAP IOT EMT FPE KILL BUS SEGV SYS PIPE ALRM TERM >STOP TSTP CONT CHLD TTIN TTOU TINT XCPU XFSZ >However on microport(sysV) many of these dont exist. The ones >Id like are TSTP STOP CONT. How do you "stop"/suspend a process >in sysV?. > Actually, on sysV there is no job control like there is under BSD, though a number of people have suggested possible ways of implementing it. You could call sleep or alarm within a program to "suspend" it; you might be able to use one of the user defined signals, and have a process go to sleep when it received that particular signal. > And finally, how does one find out about "the kernal" >without having a source license? Are there any good books that I >should be ordering? The kind of books that out line how to get >the best out of unix, and tricks of the trade etc... > >Ive seen some good ones, like > Advanced Unix Programming (Marc J. Rochkind) (great book!) > The Minix book was great also, but its not Unix. > > Just thought Id ask... > > Neville One of the best that I have seen is by Richard Back, The UNIX operating System - if that name isn't completely correct its real close. It's an exceptional book, and for anyone trying to learn about the kernel highly recommended. Also the XINU Operating Sytem by Comer is a book that might be useful as well; it's not about UNIX per se but uses alot of the ideas from UNIX. > >BTW. If only(and any) of the big boys can afford to have a >Unix source license, I cannot see the logic in making the >source so sacred. It just means that the little (and interested) >guys go without and have to wait for their hardware suppliers >to patch found(and annoying) bugs. You could use adb :-) :-) :-) :-) Yoseff ****************************************************************** yf In Xanadu did Kubla Khan a stately pleasure dome decree But only if the NFL to a franchise would agree. ARPA: francus@cs.columbia.edu UUCP: seismo!columbia!francus
meissner@xyzzy.UUCP (Michael Meissner) (07/16/87)
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