Xref: utzoo comp.sources.wanted:14922 alt.sources.wanted:826 comp.unix.programmer:862 comp.unix.internals:1848 comp.unix.misc:841 Path: utzoo!utgpu!cs.utexas.edu!uunet!rbj From: rbj@uunet.UU.NET (Root Boy Jim) Newsgroups: comp.sources.wanted,alt.sources.wanted,comp.unix.programmer,comp.unix.internals,comp.unix.misc Subject: Re: Modifying a unix process table on the fly Message-ID: <118873@uunet.UU.NET> Date: 19 Jan 91 00:48:41 GMT References: <5962@rtech.Ingres.COM> Followup-To: comp.sources.wanted Organization: UUNET Communications Services, Falls Church, VA Lines: 21 In article <5962@rtech.Ingres.COM> dan@squid.ingres.com (Dan Dick "Squid Mgr") writes: >We have a process that is hung waiting for a device driver that will never >respond. Therefore, that process cannot die--even with a kill -9 . >Does anybody have experience flipping the DISK-WAIT flag so the process can >think it is ok to die gracefully? I have always thought that setting the "Wait Channel" to the address of the lightning bolt (lbolt) would be a nice way to either (1) unwedge a process, or (2) crash the system. I would think it would depend on the particular type of hang involved. I used to work with a guy who wrote a "user level sceduler" by writing into the systems proc tables. This was for a government procurement to make the benchmarking suites run faster. We were supposed to tune their kernel and we couldn't get them to put the stuff in their kernel, so it had to be done as a user process. -- Root Boy Jim Cottrell Close the gap of the dark year in between