home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / sysv386 / 13991 < prev    next >
Encoding:
Internet Message Format  |  1992-09-03  |  2.4 KB
  1. Path: sparky!uunet!stanford.edu!rutgers!att-out!cbnewsj!dwex
  2. From: dwex@cbnewsj.cb.att.com (david.e.wexelblat)
  3. Newsgroups: comp.unix.sysv386
  4. Subject: Re: No more processes ?  It's a lie !
  5. Message-ID: <1992Sep3.184855.29411@cbnewsj.cb.att.com>
  6. Date: 3 Sep 92 18:48:55 GMT
  7. References: <dtlnb9m.enertec@netcom.com>
  8. Organization: AT&T
  9. Lines: 44
  10.  
  11. In article <dtlnb9m.enertec@netcom.com> enertec@netcom.com (Rick Whiffen) writes:
  12. > I am posting this here in the hope that someone can provide
  13. > me with a clue for the solution to this problem.
  14. > 
  15. > We are running ISC 3.0 Unix, SyBase, some client applications
  16. > and X-windows(r4) on a 486 platform and are experincing a
  17. > strange problem.
  18. > 
  19. > While running, the system will output (on the F8 console) messages from
  20. > sybase "no more processes" and the X server Xvga "Select waitforsomething
  21. > errno=11".  Both software packages seem to believe that the process table
  22. > is full.  I have verified that this is not the case ( NPROC=200 and ps -ef
  23. > yields 78 entries).  The system seems to function fine (applications perform
  24. > thier expectted tasks properly), but we are concerned that we exhausting some
  25. > system resource that will bite us in the future.  Scanning the man pages indicates
  26. > that errno 11 can be returned by system calls that have nothing to do with
  27. > process manipulation (most notably message and STREAMS calls).  Use of "crash"
  28. > and the strstat command, however indicates that no stream parameters have been
  29. > exceeded.
  30. > 
  31. > If anyone can provide some insight related to this problem, the help would
  32. > be greatly appreciated.
  33. > 
  34. > 
  35. > Thanx in advance
  36. > 
  37. > John Feras
  38. > 
  39. > enertec@netcom.com
  40. > 
  41.  
  42. Check the per-user process limit (MAXUPROC?).  There are two number-of-process
  43. limit: the size of the process table, which applies to the entire system,
  44. and the per-user process limit, which keeps single user from sucking up the
  45. whole process limit.  So it is very possible, especially when using lots
  46. of windows, for a user to run out of processes while the system has plenty
  47. of space left.
  48.  
  49.  
  50. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  51. David Wexelblat             | dwex@mtgzfs3.att.com  | Somebody get me a
  52. AT&T Bell Laboratories      | ...!att!mtgzfs3!dwex  |   cheeseburger!
  53. 200 Laurel Ave - 4B-421     |                       |      
  54. Middletown, NJ  07748       | (908) 957-5871        | --Steve Miller Band
  55.