topic Re: core file location in Operating System - HP-UX

core file location

Davor Matijasevic — Fri, 20 May 2005 02:38:10 GMT

Does anyone know a way on HP-UX 11.x to change the location in which the core file of a process will appear, beside setting the working directory before the process is started? On 10.x we had savecore, but it does not exist on the 11.X any more (or was I simply unable to find it?).

All answers appreciated.

Thanks,
Davor.

Re: core file location

Fred Ruffet — Fri, 20 May 2005 02:45:26 GMT

As you said, core file is generated in the working directory of the program. You can do a wrapper to cd before launching program, but, it may not be a good idea to generate core files in the same place, as long as they have the same name...
Anyway, if the program do a cd itself, there's nothing you can do (AFAIK).

Regards,

Fred

Re: core file location

Nguyen Anh Tien — Fri, 20 May 2005 02:56:54 GMT

pls find
#find / -name core -exec ll {} \;
you will find out the location of each core file.
tienna

Re: core file location

Stephen Keane — Fri, 20 May 2005 03:32:23 GMT

I thought savecore was used to save system dumps, not core files from user processes. If this is the case, the equivalent in HP-UX11 is the /etc/rc.config.d/savecrash config file.

I haven't used 10.20 for a while, so apologies if my memory isn't what it ought to be.

Re: core file location

Stephen Keane — Fri, 20 May 2005 03:33:24 GMT

Oh, and the savecrash (1M) command!

Re: core file location

Henk Geurts — Fri, 20 May 2005 03:55:34 GMT

hi David.
create a soft link to redirect the core to another location.

regards.
Henk

Re: core file location

Davor Matijasevic — Fri, 20 May 2005 08:27:18 GMT

Hi all!

Savecore can be used to save process cores as well, it was very useful and I was sorry to see it go away. Savecrash, on the other hand, can only be used for system crashes which to be honest scares me a little - we are in a way warned to expect system crashes so there's no point in worrying over process coredumps :)

Thanks to all for your replies, it seems that doing a cd is the only way around it, since we already tried the softlink but we can not use it for reasons I will not mention it on a public forum :)

Re: core file location

Bill Hassell — Sat, 21 May 2005 09:18:26 GMT

savecore (on your 10.20 systems) must have been a custom program. After checking several 10.20 systems, savecore is strictly an OS crashdump processor and has no options to control program core dumps. savecore is actually an after-crash processor. It is run during reboot to check the dump area for a valid crash and copies the raw data into a file or to a tape.

savecrash performs the same function in 11.xx and later. Every operating system can crash, especially if it is not up to date on patches. But in both cases, savecrash and savecore performa the same task: copy an HP-UX crashdump into a file or onto a tape.

When a program crashes, the OS follows a standard set of steps to create a core file. The first is to check the environment for a ulimit value that restricts the size of a core file. If the core option is 0, the core dump is aborted and no file is created. Otherwise, the size of the core file is limit ed to the setting of ulimit -c.

Creating a core file has a fairly significant impact on the system, especially multi-processor systems where all processors must be signaled with a spinlock. The spinlock limits all processors to not run certain parts of the OS until the core dump is complete.

To eliminate all core files, the simplest way is to run ulimit -c 0 which sets the size of a core file to zero (which equals no file). If yuou have developers writing (fixing?) code, you can put:

ulimit -Scc 0

in /etc/profile and now the default will be be zero core files unless the user changes ulimit -c to a non-zero value. NOTE: ulimit options are not available in ksh until the most recent patch for ksh. It has been always available with the HP-UX POSIX shell.

Re: core file location

Bill Hassell — Sun, 22 May 2005 21:57:34 GMT

Note: ulimit -Sc 0
The extra c was a keyboard glitch.