home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / internal / 1699 < prev    next >
Encoding:
Internet Message Format  |  1992-08-16  |  2.1 KB
  1. Xref: sparky comp.unix.internals:1699 comp.unix.sysv386:13233
  2. Newsgroups: comp.unix.internals,comp.unix.sysv386
  3. Path: sparky!uunet!virtech!cpcahil
  4. From: cpcahil@virtech.uucp (Conor P. Cahill)
  5. Subject: Re: SIGKILL problem with Interactive
  6. Message-ID: <1992Aug17.110710.20862@virtech.uucp>
  7. Keywords: SIGKILL Interactive
  8. Organization: Virtual Technologies Inc.
  9. References: <1992Aug14.124846.27924@crash>
  10. Date: Mon, 17 Aug 92 11:07:10 GMT
  11. Lines: 33
  12.  
  13. gpitcher@crash.cts.com (Glenn Pitcher) writes:
  14.  
  15.  
  16. >For instance, I have one job that is recycled each night.  It's first 
  17. >terminated by using 'kill -9 <pid>'.  Most of the time it works but last
  18. >night the job was in a infinate loop trying to kill this thing off.  Another
  19. >example is a little script that kills users off just before I perform a 
  20. >system backup at 0200.  Here I also use kill -9 (I know it's crude) and it
  21. >works... most of the time.
  22.  
  23. Most likely the jobs you can't kill are asleep within the kernel at too high
  24. of a priority level to get woken up by a signal.  This can happen for several
  25. reasons, but the most likely culprit is an i/o request to a device in which
  26. the device driver put the program to sleep at an uninteruptable level.
  27.  
  28. This is easy to re-generate.  Just run "ls -lR /" and when the output 
  29. starts, enter <Ctrl>-s.   After a few moments the output buffer will fill
  30. and the program will be put to sleep pending the receipt of a ctrl-q.
  31. At this point, signals are almost always disabled and if you send a kill -9,
  32. the program will not die (although the signal will be delivered as soon as 
  33. a ctrl-q is delivered from the terminal and the program will die then)
  34.  
  35. >Also, occasionally, my backup job (which is started by cron) simply sits
  36. >in the process queue sawing logs (asleep :-) ).  Nothing I do will wake it
  37. >up and I have absolutly no idea as to why my system is doing this.  I even
  38.  
  39. Perhaps a problem with the tape driver?
  40.  
  41. -- 
  42. *** SENTINEL(tm) The ultimate Debugging Environment - email for more info ***
  43.  
  44. Conor P. Cahill              (703)430-9247            cpcahil@virtech.vti.com
  45. Virtual Technologies, Inc.  46030 Manekin Plaza          Dulles, VA 21066 
  46.