core dump space

[Unix Administrator_6]

I dont have enought dump space on any of my boxes. I would at least need 2 gig, which isn't an option at the moment to have just sitting there waiting for the next core dump.

I saw this in the tech knowledge base:

Use these steps to prevent the core dumps from consuming large amountsof disk space:
1. Create a core file in the directory in which you expect the core file: > core
2. Change the core file to read-only:
chmod 444 core
The core files will no longer be written to disk.

Is that right? So can I just chmod for my /var/adm/crash directlry and that will work?

[Alan Riggs]

Or you can simply set SAVECORE=0 in /etc/rc.config.d/savecore (I am assuming you are running 10.20 with a core size that large). This keeps the system from trying to automatically save the core after a crash.

[Unix Administrator_6]

Sometimes I need the core dump for HP to analyze, but I hate wasting the space, so I do need it though.

[John Palmer]

Sheri,

The 444 permissions technique is to prevent the creation of large core dumps from 'normal' applications (which dump to a file 'core' in their current directory)rather than a system crashdump which is saved to /var/adm/crash.

As per Alan's post, setting SAVECORE=0 will prevent the system restart from saving a crashdump. If you are on HP-UX 11 though the method for saving crashdumps has been rewritten so that only some parts of memory are actually dumped rather than all of it. You will need much less space in /var/adm/crash.

Regards,
John

[Alan Riggs]

You can still run the savecore command manually after reboot. I assumed this was what you intended. If you have a dedicated dump device (as opposed to sharing primary swap) then you can wait indefinitely until actually writing the dump to file. If you share primary dump and swap, you will need to issue the savecore command before memory fills and pages start swapping to ensure an uncorrupted dump.

With a dedicated dump device, turning savecore off on reboot also speeds recovery time since the boot will not be delayed while the core is written.

[Cheryl Griffin]

There is a crash files written to /var/adm/crash which others have outlined how to disable, but the document you alluded to will not affect crash files but core files that have been left behind by an application or failed command.

My point is that these are two separate concepts.

[Anthony deRito]

Sheri, there is a difference between what happens just afer a system panic and what happens with savecore. When a panic occurs, the kernel will attempt to dump the contents of system RAM and a copy of the kernel into the defined dump space. I believe this is what you are referring to when you say "I dont have enought dump space" Is it not? You can get a glimpse of whether this is true by looking at the output of dmesg. You will see:

"WARNING: Insufficient space on dump device to save full crashdump.
Only 524288000 of 2147484672 bytes will be saved."

However, when the system reboots, the /sbin/init.d/savecore script checks the dump area to see if a core dump exists. If a dump exists, then by default, it will be saved underthe directory /var/adm/crash. This space may or maynot be also the dump area. Use lvlnboot -v to see how your dump is used.

The question I have for you is: does your procedure prevent dumps from occuring period or does it prevent savecore from performing its thing?

Tony

[Alan Riggs]

Tony,
I do not believe there is any way to prevent the system from dumping ram into configured dump space at a crash. The procedure I gave was meant to address space concerns in /var/adm/crash (or other cooked filesystems).

[Anthony deRito]

Thanks Alan for clarifying!

Tony