[comp.sys.sgi] preventing core dumps

glennrp@BRL.MIL (Glenn Randers-Pehrson, WMB) (02/28/90)

Brian Sturgill <brian@cs.utah.edu> wrote that he prevents IRIX from
making core dumps by making a symbolic link for /core to /dev/null.
I've been accomplishing the same by making a zero length core with
mode 0.  But I really wish the operating system designers would provide
an environment variable $NO_CORE or the like that could be used to
prevent core dumps.   ...Glenn Randers-Pehrson <glennrp@brl.mil>

doelz@urz.unibas.ch (Reinhard Doelz) (03/01/90)

Talking about cores. NOCORE is okay, 

... or even a parameter MAXCOREDUMPSIZE, because sometimes a small 
core is better than nothing, and testing routines it is annoying that 
your disk gets filled  up with a core which might bother other processes. 

Reinhard 

pj@sam.sgi.com (Paul Jackson) (03/02/90)

In article <221*doelz@urz.unibas.ch> doelz@urz.unibas.ch (Reinhard Doelz) writes:
| Talking about cores. NOCORE is okay, 
| 
| ... or even a parameter MAXCOREDUMPSIZE, because sometimes a small 
| core is better than nothing, and testing routines it is annoying that 
| your disk gets filled  up with a core which might bother other processes. 

Coming soon to a theater near you.  The next IRIX major
software release includes support for Berkeley style get
and set rlimits, including "limit coredumpsize".  By
setting this limit large enough to include a process's
stack, dbx will provide you a stack backtrace without you
having to dump a Multi-Megabyte core of your data segment.

				Thanks, take care ...
				Paul Jackson (pj@asd.sgi.com), x1373

YATES@C.CHEM.UPENN.EDU ("YATES, JOHN H.") (02/11/91)

Is there a way under IRIX 3.3.1 to prevent core dumps or limit their
size? (e.g. through an environment variable set by a user, or by root,
or an /etc/config file).
Thanks, John
yates@c.chem.upenn.edu

amoss@SHUM.HUJI.AC.IL (Amos Shapira) (02/15/91)

YATES@C.CHEM.UPENN.EDU ("YATES, JOHN H.") writes:
>Is there a way under IRIX 3.3.1 to prevent core dumps or limit their
>size?

It's part of the process attributes, do:

limit core 0

(it's a csh builtin command). To find out about your limits just do "limit".

Hope this helps,
Amos Shapira
Hebrew University
Jerusalem, Israel
amoss@shuldig.huji.ac.il

aspgpas@cidsv01.cid.aes.doe.CA (Peter Silva) (02/19/91)

In article <amoss.666606038@shum>, amoss@SHUM.HUJI.AC.IL (Amos Shapira) writes:
|> YATES@C.CHEM.UPENN.EDU ("YATES, JOHN H.") writes:
|> >Is there a way under IRIX 3.3.1 to prevent core dumps or limit their
|> >size?
|> 
|> It's part of the process attributes, do:
|> 
|> limit core 0
|> 

uh... That's

limit coredumpsize 0


--
Peter Silva			OS Support 
psilva@cid.aes.doe.ca		Dorval Computing Centre
(514) 421-4692			Atmospheric Environment Service

glen@meteor.wisc.edu (Glen Ecklund) (02/21/91)

Is there any way to prevent core dumps from being generated?
dbx generated a 60Mb core dump yesterday, filled up the disk, and crashed
the system.

I'm running Irix 3.2 on a 4D 220S.

Thanks
-- 
Glen Ecklund				glen@meteor.wisc.edu
Department of Meteorology               (608) 262-3086
University of Wisconsin, Madison

glen@meteor.wisc.edu (Glen Ecklund) (02/22/91)

In article <1991Feb20.200617.12807@meteor.wisc.edu> glen@meteor.wisc.edu (Glen Ecklund) writes:
>Is there any way to prevent core dumps from being generated?
>dbx generated a 60Mb core dump yesterday, filled up the disk, and crashed
>the system.
>
>I'm running Irix 3.2 on a 4D 220S.
>
>Thanks
>-- 
>Glen Ecklund				glen@meteor.wisc.edu
>Department of Meteorology               (608) 262-3086
>University of Wisconsin, Madison

I've received several responses (thanks to all).  There have been 2 
main suggestions:

1)  limit coredumpsize
    Unfortunately, we don't have limit on 3.2

2)  create an empty core file and make it non-writeable.
    Good idea when one is expecting such a problem, but I'd like a
    solution which most of our naive users could have in their .cshrcs
    and not think about it.  (OK, we could alias mkdir to create a
    nonwriteable core file in the new directory)

Someone did indicate that later releases have limit.  I guess that's
another thing we can do when we find the money to upgrade.
-- 
Glen Ecklund				glen@meteor.wisc.edu
Department of Meteorology               (608) 262-3086
University of Wisconsin, Madison