Core files are just a process dump (image from physical memory) when the process terminates abnormally. These files are very important to find the root cause of process(application/DB) failure. Normally , application/DB need to send these core files to application vendor to fix this issue. Otherwise system administrator’s job will become hectic to perform the core file clean up all the time to prevent the root filesystem full.
Crash-dump is also similar to core-dump but instead of dumping for the process failure, it creates the memory dump for Operating system crash/failure. This crashdump file should be sent to Operating system vendor to find the root cause for the system crash.
We will see the crashdump & coredump configuration Oracle Solaris 10/11 .
Crashdump:
You can see the crashdump location using dumpadm command without specifying any option.
# dumpadm Dump content: kernel pages Dump device: /dev/dsk/c1t1d1s1 (swap) Savecore directory: /var/crash/uxarena Savecore enabled: yes
Modifying the crashdump directory:
# mkdir /var/crash/uxarena5 # chmod 700 /var/crash/uxarena5 # dumpadm -s /var/crash/uxarena5 Dump content: all pages Dump device: /dev/dsk/c0d0s1 (swap) Savecore directory: /var/crash/uxarena5 Savecore enabled: yes
Now the system will use the new directory to store the crash dumps. Setting the rights of the directory to 700 is very important. The crash dump may contain confidential information, thus it could be dangerous to make them readable by anyone else than root.
Core dumps:
You can see the application coredump location using the below command. To enable ,you can user -e option.
# coreadm global core file pattern: global core file content: default init core file pattern: core init core file content: default global core dumps: disabled per-process core dumps: enabled global setid core dumps: disabled per-process setid core dumps: disabled global core dump logging: disabled
There are two patterns in the coreadm options.Those are global pattern & init pattern.
node1-CGI#coreadm -g /var/core/core-%n/core_%n_%f_%u_%g_%t_%p
node1-CGI#coreadm -i /var/core/core-%n/core_%n_%f_%u_%g_%t_%p
node1-CGI#coreadm
global core file pattern:/var/core/core-%n/core_%n_%f_%u_%g_%t_%p
global core file content: default
init core file pattern: /var/core/core-%n/core_%n_%f_%u_%g_%t_%p
init core file content: default
global core dumps: enabled
per-process core dumps: enabled
global setid core dumps: enabled
per-process setid core dumps: enabled
global core dump logging: enabled
Thank you for reading this article. Please leave a comment if you have any doubt. I will get back to you.
Forcing a core dump:
Let’s assume if you want to have an core dump of a running process on your system:
# ps -ef | grep “bash” | grep “uxarena” uxarena 8345 3475 0 21:29:19 pts/11 0:10 bash Okay, now we can trigger the core dump by using the process id of the process. # gcore 8345 gcore: core.8345 dumped You can analysis using mdb command. # mdb core.8345 Loading modules: [ libc.so.1 ld.so.1 ] > $c
Forcing a crash dump:
you can force a crash dump, too. It’s quite easy. There are many ways to force crash dump. By default , you should always use ,
# reboot -d (To generate the crashdump)
You can also trigger it with uadmin command. It will bring down the system in few seconds .(Do not use it in production environment). You can find the crashdump file in /var/crash location. (Run dumpadm command to know crash file location)
bash-3.2# uadmin 5 0 panic[cpu0]/thread=db47700: forced crash dump initiated at user request d50a2f4c genunix:kadmin+20c (5, 0, 0, db325400) d50a2f84 genunix:uadmin+8f (5, 0, 0, d50a2fac, ) syncing file systems…3 2 1 done dumping to /dev/dsk/c1t1d0s1, offset 108593152, content kernel 100% done: 31255 pages dumped, compression ratio 5.31, dump succeeded Press any key to reboot.
Refer this article, if Solaris operating system is hung & force to generate the crashdump.
Hope this article is informative to you.