Dharmosoth Seetharam <dseetharam at inbox.com> writes: >>>> Basic questions. >>>> 1) Do you have panic on oops set? >>>> I think that setting more than anything else will be the >>>> difference in what shows up in /var/log/messages. >>> >>> Yes, in my case panic_on_oops was set with 1 >> >> That is the reason thing don't show up in /var/log/messages >> because you panic before syslog has a chance to write the messages. > > Thanks. > So, if panic_on_oops set with 0(default), we will get all the > needed info like stack traces, bug info etc. in /var/log/messages then reboots. > > Or do we need to apply any specific patches to get info in /var/log/messages? > >> >>>> 2) Have you tried a dry run and confirmed you can get a crash dump? >>> >>> No, I haven't tried this. >> >> It sounds like you have not been getting the coredumps when problems >> happen. Running a simple test run to Alt-sysrq-c to confirm >> that things are basically setup ok is a good idea. >> > Sorry, I misunderstood your question. > I have gave dry run and confirmed that the dumps are getting saved in particular dir and able to analyze. > > I did in both the ways like > 1 - echo c > /proc/sysrq-trigger > 2 -Alt -sysrq -c Then unless you are having problems capturing core dumps in real failure situations it sounds like all is well with the world. A kernel oops is normally not fatal and the kernel tries to limp along allowing for better diagnostics etc. This allows klogd to read the kernels message buffer and pass the kernel messages to syslog which writes the messages to /var/log/messages. After a kernel panic nothing is allowed to happen which prevents user space from writing to /var/log/messages in the usual way. If you want data in /var/log/messages it appears you have two choices. 1) Post process a core dump as Neil suggested and feed the kernel log buffer to syslog. 2) disable panic on oops. The system will continue to limp along allowing user space to write to /var/log/messages. Eric
