One issue a CNC faces on a daily or weekly basis is Zombie kernels. Usually call object kernels go zombie causing applications to fail and cause data integrity issues. This blog explains how to analyze a kernel that went zombie and how to provide the needed information to the developers or use Oracle support to help fix the problem.
Scenario
A call object kernel goes zombie.
What can we do? What places to look for details.
- Server manager web logs
- jdenet_n logs on the enterprise server
- call stack dmp file on the enterprise server if available
The above three locations are enough to capture all the necessary details.
Steps
- Open server manager and capture the zombie kernel pid for the enterprise server
- Scan the jdenet_n logs on the enterprise server which will record the zombie pid with the call stack. The string to search for “net process: process 3528 set to Zombie”
Highlighted pid is just an example. - Search for the dmp file if exists in the enterprise server logs folder. The dmp file name format is:
jde_pid_xxxxxx_1_dmp where xxxxx is a random number - Provide the client development team with all the above details
- The call stack dump is always read from bottom up
- You can also check the web server logs to find the user, application associated with the kernel pid that went zombie
- Once you have all the information you can go to Oracle support for standard business function zombies and look for an ESU. Apply the ESU and test the application.
If the object is custom you provide all the details from the jdenet_n logs, call stack dmp to the developers so they can fix the code.