So you might want to know more about how crashdc is organized. Well here are a few pointers.
crashdc is a shell script that is called from a kdump mechanism which is triggered when a vmcore dump file gets created. The file it creates is named crash-data-{date}.txt Unfortunately (for me), this mechanism is different in all three implementation that crashdc supports :
- RHEL5 : kdump_post
- SLES10 : KDUMP_TRANSFER
- SLES11 : KDUMP_POSTSCRIPT
It can also be run interactively on an existing vmcore to generate the crash-data-{date}.txt file afterward.
I will try to go in a little more details about each of the automated mechanisms. But it is important to know that crashdc itself is identical for all three distributions. The only thing that changes is the run-crashdc-{distro}.sh shell that is executed by each one of those mechanisms.
RHEL5’s kdump_post
This is the most straightforward. When uncommented, the kdump_post variable in /etc/sysconfig/kdump is setup to run the /var/crash/script/kdump_post.sh script. This script is in fact a symlink to /usr/bin/run-crashdc-rhel5.sh which takes charge of finding vmcore’s location, and to invoke crashdc.
SLES10’s KDUMP_TRANSFER
SLES10’s implementation is more complex. When KDUMP_TRANSFER is defined, the command it invokes becomes responsible for reading vmcore’s data out of /proc/vmcore and to store in in a file. Otherwise, it is the save_core shell function from /etc/init.d/kdump that does that.
So /usr/bin/run-crashdc-sles10.sh has an identical copy of the save_core function (yes I copied it) that will copy the vmcore file. The rest of the script does the same thing than for RHEL5, which is to invoke crashdc with the appropriate parameters.
SLES11’s KDUMP_POSTSCRIPT
Once again, SLES11’s implementation is different. When invoked from witihin the kexec environment, the script pointed to by KDUMP_POSTSCRIPT runs in an environment where the / file system is memory resident, and the real disk-based / file system is mounted in /root. So the /usr/bin/run-crashdc-sles11.sh knows all so it is still able to invoke crashdc correctly.
Those three mechanisms are all KDUMP specific handles. This mean that they run right after a kernel panic, when the KDUMP kernel is running and before a reboot has been done.
Post Reboot processing
Some system administrators might not like the idea that unnecessary processing is done in that context. This is why one last script has been developped : /etc/init.d/crashdc This script can be used when the system reboots to its regular environment to generate the crash-data-{date}.txt file.
With this method, the crash-data-{date}.txt will only get created when the system reboots on the regular kernel. The current limitation is that it will only process the latest vmcore created in order to avoid extra processing in case of multiple kernel panics. Yet, there should be an option to manually process all vmcores where crash-data-{date}.txt has not been found.
Right now, this script only exists in my mind so there are chances that it might evolve quite a lot before it gets done.
So I hope that this brief post is clear enough to highlight the main mechanisms used by crashdc.
