core files

[Pando]

dear gurus,

I found some core files in my hp-ux and they are taking too much disk space. I would like to know what is this core files and is it safe to me to delete it without affecting other files?
Is is used by the system?

Maximum points to all correct answers.

Thanks!

[Bill Hassell · Accepted solution]

The core files are caused by programs which have crashed or abnormally terminated. To see the name of the program which crashed, use the file command like this:

file /some_directory/core

Then remove the file. They are not used by HP-UX in any way. If you have programmers that are writing programs, you can move the file to the programmer's work area and they can figure out what to do.

[Raj D.]

Pando,

Core files gets generated when any process gets terminated abnormally, or due to Memory violation , illegal operation , floating point exceptions, or due to user initiated kill signals.

You can delete this files to save disk space, and you can check the file with # strings core, to see which application generated the core file.


Cheers,
Raj.

[rariasn]

Hi Pando,

# file core
core: core file from 'bma' - received SIGABRT

Posible "core" from "bma" (data protector aplication)

# strings core

# rm core or mv core

rgs,

[Yogeeraj_1]

hi,

core files are of no use if you don't want to investigate further into the root cause of the core dump/process crash.

In case, you go into troubleshooting of the process that crash then you may be required to analyse the core dump to get appropriate information.

hope this helps!

kind regards
yogeeraj

[amit mehta_2]

Hi Pando,

HP-UX will dump the core file in the working directory and if you get multiple core dumps,the older core files in that same directory will get replaced by the newer one.
so if you are planning to save multiple core files,use following:
$ mkdir -p /var/core 2>/dev/null
$ coreadm -g /var/core/core.%p.%t
$ coreadm -I /var/core/core.%p.%t
$ coreadm -e global
$ coreadm -e process
Now Verify your new settings:
$ coreadm

Beside this you may want to read,coreadm(2M)

~amit

[James R. Ferguson]

Hi:

On HP-UX, the 'coreadm' command mentioned by Amit, does *not* exist. The command belongs to Sun/Solaris!

Regards!

...JRF...

[Ignacio Javier]

Hello:

For aditional information,
man core

regards

[Ralph Grothe]

As written,
coreadm is a nice feature from the Solaris OS.
Nevertheless, the shell gives you a limited
control over your core files by the ulimit command.

e.g.

$ sleep 600 &
[1] 2994
$ kill -s SEGV %1
$ jobs
[1] + Memory fault(coredump) sleep 600 &
$ ll -n core
-rw------- 1 101 20 189932 Jan 12 15:44 core
$ file core
core: core file from 'sleep' - received SIGSEGV
$ rm core
$ ulimit -c
4194303
$ ulimit -c 0
$ sleep 600 &
[1] 3000
$ kill -s SEGV %1
$ jobs
[1] + Memory fault sleep 600 &
$ ll -n core
core not found

[Doug Burton]

Some ways to check the core file to get a better idea what's going on or where it came from:

What made the core in the first place:
file core

To get the libs used:
what core

To debug the stinker:
gdb -c core

To debug the stinker:
gdb ProgramName -c core

Also see HP doc - KNC071499001

[Sp4admin]

Hi Pano,

You can gunzip the file for now if space is a issue. Most the time you can contact hp and ftp the core file to them to be review for the reason of the crash. Then just go ahead a delete them.

Hope this helps,
sp,

[Dennis Handly]

As mentioned by Bill you should at least use file(1) to see what is causing the problem. And you may not need more than the last one for any program/signal.

To add on what he said about saving them for developers, if you are going to move them to another system, you need to use gdb's packcore command. (A corefile is useless without the executable and all shared libs that were used.)

Contrary to Raj and rariasn say, you should NOT use strings on core because you may get confused and blame the wrong thing.

Doug is correct that you can use gdb on the executable and core to get a stack trace. This may allow you to identify your problem as something already known, or with a patch.

You can download wdb for free at:
http://www.hp.com/go/wdb

>Sp4admin: You can gunzip the file

I assume you meant gzip? ;-)

>Most the time you can contact hp

I'm not sure if HP will do that for core files for user applications. Were you thinking of panic dumps in /var/adm/crash/?

[D Block 2]

Pando, How are you .. I understand you pain here...

Please assign points to Bill H. and Dennis..

here's my 5-cents for you..

I agree with Dennis and a pointer back to Bill H.

but I have seen that a core file can dump it's self into a new core file and cause space problems..

to help you with this problem..
try this one..

locate the core file itself and set the file modes to non-write..

a little learning here..

1. core file is located in /x/y/core
2. ls -l /x/y/core
it is very big in size, so reduce the size to ZERO bytes
3. $ >/x/y/core
ls -l /x/y/core
now the size is zero bytes
4. change the mode on the file so it is NEVER ABLE TO WRITE ON TOP OF ITSELF
chmod 444 /x/y/core

this is not clean here.. but can help to prevent space problems..

follow up on Dennis and Bill's points..

think about this one.. even an WebServer like Apache can grow in size. because of a program bug.. if the program grows and grows.. and then performs something that the kernel does not allow, hence Segmentation fault, page-fault, bus-error..

again, follow Dennis and Bill..

[D Block 2]

Pando,

think about it.. even the shell "ksh" or "sh" can sometimes cause a core file..

If the running process is growing and demanding more memory and space, then the size of the process in memory is big.

do you agree ?

Okay, let's try this one:

find all the active processes on your system and report the size of the processes

1. ps -efl
the "l" flag shows the total memory of the process, but yet it might have some Dynamic Libraries that it is using.. which is also added to the number..

say, the process "Core" dumps and creates a 'core' file, then the entire memory footprint (think of CSI on TV here) is now copied onto Disk Space. this can be a killer, but yet it may take many blocks of disk space.

if you like, you can try some cool tools of HP-UX here:

1. assume core file is /x/y/core
2. run the cat command using the -v option
$ cat -v /x/y/core | more
3. notice the first or second page of the output ? Does this show any program name, or do you find like an Application name ? Then, this is a clear validation that the program name file is called, let's just say "abc_program".

at this point you do not know where is the location of this executable name "abc_program", do you ?

so, try to find it using the "find" command, example.. follows assume "abc_program" was printed using the "cat -v core" output, then..


4. find the path of the "abc_program" file

$ cd /
$ find . -exec ls -l {} -name abc_program -print \;

note, this might take 5 or 10 minutes to run, if you do find the Full Directory Path name of the executable, then prove it to yourself that the "core" file matches the executable file name by running "adb" command.

example of adb

5. adb /filesystemx/abc_program /x/y/core
$C
$q

bingo.. you now have confirmed that the program that caused the 'core' file is called /filesytemx/abc_program
note this matches the /x/y/core file.

good hunting..

rgds,
T.

[Dennis Handly]

>Tom: locate the core file itself and set the file modes to non-write..

I just create a directory called "core".
As mentioned by Ralph you can use ulimit.

>2. run the cat command using the -v option

"file core" handles this directly.

$ cd /
$ find . -exec ls -l {} -name abc_program -print \;

You can speed this up by using -name before -exec. And no need to use -print if you use ll:
$ find / -name abc_program -exec ll +

(And replace \; by +.)

>5. adb /filesystemx/abc_program /x/y/core

It is much much easier to use gdb.

[D Block 2]

Hey Dennis.. I like the speed up options you suggested.. the "+" is cool, I'll have to try this one.

The "file" command is important to us, in that, some executables might be of 11.11 PA-RISC and some might be of 11.23 Itanium..

clearly this command "file" is very helpful to all..

question for you: let's say, someone load a binary file of a.out format for 11.23 itanium but on a older OS 11.11 PA-RISC ?

This has happened to me..

Does the "file" command on a 11.11 PA-RISC know about the "Magic Number" for an 11.23 Itanium ? I strongly feel there should be a smart version of the "file" command that notes the identity of all binary versions.. be it Itanium, PA-RISC, or even Linux.

rgds,
T.

[Pando]

Dear Gurus,

I was away over the weekend and i was so surprised about the helped i got from you about the 'core' files topic! Thanks guys for the answers! This forum really helps!

Brgds,

Pando

[Dennis Handly]

>Tom: Does the "file" command on a 11.11 PA-RISC know about the "Magic Number" for an 11.23 Itanium?

You need to be on 11.23 PA for file(1) to work better. Otherwise if you look closely you can still tell:
On 11.11:
$ file a.out # +DD32 IPF
a.out: ELF-32 executable object file
$ file a.out # +DD64 IPF
a.out: ELF-64 executable object file
$ file a.out # +DD64 PA
a.out: ELF-64 executable object file - PA-RISC 2.0 (LP64)
On 11.23, IPF:
$ file a.out # On IPF +DD64
a.out: ELF-64 executable object file - IA64

[Dennis Handly]

>JRF: On HP-UX, the 'coreadm' command mentioned by Amit, does *not* exist.

I'm surprised I didn't mention that this now exists on 11.31.