avoiding a crash dump

[Doug O'Leary]

Hey;

I got a *really* old box - I think it's a D220, running HPUX 10.20 - that I need to bring back to life so we can get the information off of it that hasn't been missed in the four months the box has been down and which is suddenly mission critical.

The box crashed due to a failed root disk. We were able to bring it back up once on the mirrored disk; however, the crash dump took forever to complete.

Assuming the techno-gods are with me and I'm able to get this thing up one more time, is there any way to avoid the system going through the crash dump?

I was thinking of booting to single user mode and dd'ing /dev/zero over the swap space... would that do it or is there a better way?

Any info will be greatly appreciated.

Thanks.

Doug O'Leary

[Duncan Edmonstone]

Doug,

What exactly took the time? The inital write out of the dump from memory into swap, or the write of the dump in swap into a filesystem (usuallly /var/adm/crash) after the system had rebooted?

If the former, I'm not sure how to proceed - if the latter, you can probably stop the box from writing out the dump from swap to a filesystem by finding the relevant startup script in /sbin/init.d and its config file in /etc/rc.config.d - I can't remember what this was called in 10.20, but probably something like savecore or savecrash or the like...

HTH

Duncan

[Doug O'Leary]

Hey;

I'm not sure what took the time as I was out of the office when another admin got the box back up. Now it's my turn. I'm assuming it was writing the crash to the filesystem.

The rc.config.d script is a good idea. Thanks. Should have thought of that one myself.

Doug

[Duncan Edmonstone · Accepted solution]

Dug out an ancient internal support doc - it suggested:

Modify /etc/rc.config.d/savecore, changing SAVECORE=1 to SAVECORE=0.

HTH

Duncan

[Doug O'Leary]

Hey;

savecore was it; thank you very much.

Doug