Dealing with core dump creation

[Nicolas Dumeige]

Hello Gurus,

On Solaris, coreadm offers to put all core with a filename formatting in a specific directory.

How to deal machine wide on the core dump creation on HP-UX 11.00 ?

Regards

Nicolas

[Scot Bean]

Not aware of such a utility on HPUX.

We use the 'find' cmd to locate them.

[RAC_1]

find / -type f -name core

Will give you core files on your system.

I dont think that you can control it system wide. If you do not want core to be generated, then you have few options.
1. ulimit (man sh for details.)
ulimit c 0 -- will not allow core generation.
2. Creating a core file with 000 perms will also that.
3. creating a soft link- core and pointing to /dev/null.
ln -s /dev/null core

But if you disable it, you will not kow what caused core file. file core command will give you some details on what went wrong.

Anil

[A. Clay Stephenson]

Man 5 signal for the behavior on HP-UX boxes but note that this really defines the default behavior. For almost all signals, the default signal handling can be overridden through the use of custom signal handlers. For HP-UX, the default behavior for signals that trigger the generation of a corefile is to create the corefile in the current working directory of the process.

[Nicolas Dumeige]

Clay,

I'm aware of the core creation, first PWD, then if the directory is writeable for the user, the home directory is used, and there could be another default place in case this doesn't work.

But check this :
http://www.freebsd.org/cgi/man.cgi?query=coreadm&apropos=0&sektion=0&manpath=SunOS+5.9&format=html

This is a simple sysadmin command that doesn't deal with signal per se.

I don't know how to feed an enhencement request for HP-UX, but this is clearly a good candidate !

Thk for your time,

Nicolas

[A. Clay Stephenson]

Well, feel free to make a request. If you are under support, open a case and your request will be passed along --- but, dont expect much. My personal opinion is to leave things that have been in place for decades alone --- you often break much more than you fix. I can't get too excited about where a core file gets written because the real concern is why it gets written.

People who have done UNIX a long time tend to avoid implementation specific commands and use the "lowest common denominator" approach. That way, your solutions are the most portable.

[Scot Bean]

I like the idea.

You can't find out 'why' the core file happened if you can't find the core file.

Note that on Itanium machines, the Aries product (emulator) saves cores with a prefix on the name, so a simple

"find / -name core" will not find these.

[Nicolas Dumeige]

Clay, with all du respect I must disagree.
1) Core dump creation become an issue on its own when you get filesystem full.

2) core dump are named core, whatever the binary that creates them, what ever the date ... Well that is not satisfactory. If there are several program crash, there should be several core dump.

3) In a ideal world, core dump doesn't exist. But in my world, there are core dumped by commercial application that need to be examined. I'm not paid to do Oracle R&D (I couldn't even if I wanted !!).

4) If you use only posix non specifiq tool, well forget about glance, SAM, ... Every Unix flavor has its pro and cons, the best OS would be the one providing the best of all others. Take linux for instance and the ps command, well you can usethe BSD ps aux or SysV ps -ef style, ps doesn't care what you're used to, in both case, it is ready to serve.

To me you have a very conservative point a view, in system administration that's a quality. But if people designing OS have the same attitude, taht would be mess. Boy, we would'nt have paging - it's dangerous to give memory that you don't really have... I guess you catch my drift ;-D

I stand by what I said, HP should consider coreadm for future release.

Regards,

Nicolas

[A. Clay Stephenson]

Actually I was around when demand paging was introduced and welcomed it. I also use tools like Glance and SAM -- they certainly have their place. What I don't like are changes to things that have worked the same way for a long time. e.g. Let's add a new column to ps and make it default. You just broke tons of scripts.

All of this misses the main point. The problem is not where the core file gets written (even if it fills up a filesystem) but rather that it gets written in the first place. If I write an application that dumps core, I take it as a personal failure and immediately fix it. I expect (and tolerate) no less from a vendor. I have even fixed things for major database vendors. When I find a corefile I immediately do a stack trace to let the vendor know what happened.
Many debuggers expect the corefile to be in the CWD and to be named 'core' although that can be overridden.

Of course, my approach is a little radical because I literally have not had a dumped core in years on a production box. Those applications which do not pass the Sandbox and Test just don't make it to Production.

[Gianluigi_3]

Hello Gurus,

On Solaris, coreadm offers to put all core with a filename formatting in a specific directory.

Thare are news about this on HP-UX 11.00 ?

Regards

[Stephen Keane]

My favourite experience with a core file is when trying to debug an application that very intermittantly dumped core. After several hours of effort, I finally managed to get a usable core, started up gdb to examine it and gdb core dumped, overwriting the original core!

Lesson learned, always rename a core before starting the debugger on it.

[Gianluigi_3]

Ciao Stepen
The lesson is right, but you can have more that one different cores in a short time and where you find the core you have only the last core. This is my very problem!!! I lose many cores in HP!!!

Regards
Gianluigi

[Stephen Keane]

Ciao Gianluigi

la vita non è giust

[Nicolas Dumeige]

Result : HP-UX 0 / Solaris 1