jim@baroque.Stanford.EDU (James Helman) (04/13/90)
Every time I log out from 4Sight, the X server dumps core leaving a large file in /. The fact that X dumps core, doesn't bother me in this situation. I'm already out the door. But I frequently have people complain about compile problems because of inadequate space in /tmp. My kludge of a solution was to change inetd.conf so that inetd invokes a Bourne shell script which does a "ulimit 10" before starting Xsgi. Doing a cd to a read only filesystem like /debug also works quite effectively. I now get nice little 1164 byte core dumps. (I expected to get 5120. There must be something magic about 1164, like maybe it's some header length). I wish the C shell implemented the various "limit" commands. Using these one can make much more focused restrictions, e.g. "limit coredumpsize." Ulimit is quite crude and works in this case only because (I hope) the X server never writes to disk except when dumping core. Questions: 1) Does the X server ever need to write any files? If so, this solution could cause problems. 2) I don't find any system call analogous to BSD's setrlimit(). Is ulimit all the kernel supports? Is there any way to only inhibit core dumps? Jim Helman Department of Applied Physics 6 Trillium Lane Stanford University San Carlos, CA 94070 (jim@thrush.stanford.edu) (415) 723-9127
jsw@xhead.esd.sgi.com (Jeff Weinstein) (04/13/90)
In article <JIM.90Apr12142023@baroque.Stanford.EDU>, jim@baroque.Stanford.EDU (James Helman) writes: 1) Does the X server ever need to write any files? If so, this solution could cause problems. No. Jeff Weinstein - X Protocol Police Silicon Graphics, Inc., Entry Systems Division, Window Systems jsw@xhead.esd.sgi.com Any opinions expressed above are mine, not sgi's.
gold@puck.wpd.sgi.com (Michael Gold) (04/13/90)
My favorite "hack" to limiting core dumps in / is to create a directory /core. The program cannot replace a directory with a file; thus no core dump. The obvious drawback is that you lose potential debugging information. Consider this a personal suggestion, not an official response from SGI... -- Mike