Difference between Crash dumps and Core dumps – Solaris

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.