coredump

[CAF786]

[ernie:root] dumpadm
Dump content: kernel pages
Dump device: /dev/md/dsk/d2 (swap)
Savecore directory: /var/crash/ernie
Savecore enabled: yes

[ernie:root] savecore -v
savecore: dump already processed

how can I get coredump?

 

[comtec17]

looks as if the dump is located in /var/crash/ernie

 

[cndcadams]

CAF786;

Are you trying to test this?

if so there are a couple things you can do.

1) reboot -d (do a man on reboot and you will see what -d does)

2) if you are on an older system that does not have a usb keyboard you can pull out the keyboard cable and plug it back in (it will drop you to ok prompt) then run sync and it should create a crash dump.

3) I can't remember if stop-A then sync will do it.

I would try option 1 first as these others could really screw up your system.

If you are just looking where the crash dump is then it is in /var/crash/ernie as comtec17 pointed out.

Thanks

CA

 

[CAF786]

I checked /var/crash/ernie and there is not core files.
I can do stop A and sync ...and it will does write under /var/crash/ernie. but right now when I do savecore -v .it shows........
[ernie:root] savecore -v
savecore: dump already processed.........I donot now where it is or some body deleted the files.

 

[Annihilannic]

Try savecore -v -d which should force it to save core regardless of whether it has already been processed.

You can also use savecore -L to save a dump of the running system without rebooting (may cause it to 'hang' for some time though). See the savecore man page.

Annihilannic.

 

[dandan123]

Perhaps it's unable to save it because you do not have enough disk space for the dump ?

 

[CAF786]

[ernie:root] dumpadm
Dump content: kernel pages
Dump device: /dev/md/dsk/d2 (swap)
Savecore directory: /var/crash/ernie
Savecore enabled: yes



[ernie:root] savecore -v -d
savecore: bad magic number 0
[ernie:root] savecore -L
savecore: dedicated dump device required

 

[Annihilannic]

You have to use one of the underlying slices of d2, you can't configure a metadevice as a dump device.

Annihilannic.

 

[cndcadams]

Annihilannic;

Can you elaborate on this statement. I have metadevices set up as dump device also and my crash dumps work fine.

Also I ran the commands CAF786 is running on a system that does not have metadevices as dump device and I get the same errors he is seeing.

Thanks

CA

 

[cndcadams]

Got to revise this statement a bit.

I ran below command on unit without metadvice and got;

savecore -v
savecore: dump already processed

# savecore -L
savecore: dedicated dump device required


savecore -v -d
System dump time: Wed Feb 1 11:51:00 2006
Constructing namelist /var/crash/smsserver/unix.1
Constructing corefile /var/crash/smsserver/vmcore.1
100% done: 10820 of 10820 pages saved

Then I ran on system with dedicated metadevices and got;


savecore -v
savecore: dump already processed

# savecore -L
savecore: dedicated dump device required

# savecore -v -d

System dump time: Wed Feb 1 12:01:290 2006
Constructing namelist /var/crash/v240/unix.1
Constructing corefile /var/crash/v240r/vmcore.1
100% done: 12111 of 12111 pages saved

so the savecore -v -d works fine for me. So CAF786 you seem to have some issue. what OS are you working on.

Thanks

CA

 

[CAF786]

It is sol8, I also tried on another machine that is running sol10, same problem. The only way I get coredump on sol8 machine is STOP-A AND THEN OK>SYNC.

 

[Annihilannic]

cndcadams, I'm probably thinking of Veritas Volume Manager best practices rather than DiskSuite/SVM (however I have checked some DiskSuite-only servers we have and they are set up to use underlying slices as well), but the principle is to keep the path between the OS and the dump device as simple as possible to improve chances of obtaining a crash dump. If the OS panics because of a serious bug in the VxVM or DiskSuite drivers for example, your chances of obtaining a crash dump would be pretty slim.

Annihilannic.