Hi Greetings,

How can i find a the process that crashed my linux system,

I only have the below information available.


from /var/log/messages
Mar 1 21:14:31 localhost kernel: fown: signal 29, pid 1211
Mar 1 22:00:17 localhost kernel: fown: signal 29, pid 1211
Mar 1 22:07:52 localhost kernel: fown: signal 29, pid 1211
Mar 2 01:00:13 localhost kernel: fown: signal 29, pid 1211

Mar 2 03:01:58 localhost last message repeated 2 times

Mar 2 04:00:02 localhost kernel: decode_getfattr: xdr error 10008!

Mar 2 04:05:06 localhost syslogd 1.4.1: restart.


Also I don't have kdump enabled.

I am assuming that this is due to overloading of the server.

This server runs an Oracle Database..

Please let me know what you think?

is it impossible??

Thank You Fellow Knights..!

Well, it obviously came from PID 1211. So look back through the older parts of the syslog, back to when the server was started, and find out what process 1211 was. Oracle logs may have that information too.

Enable kdump, and get Oracle to take a look at things. They'll need a trace file, probably, and some other things as well.

Hi Greetings,

Thanks for your help,

This turned out to be an issue with the IBM bladeserver firmware..upgrading to the latest firmware resolved it.

Anyway if a server is overloaded it wont reboot itself, it might crash.. didn't think of that when i posted this question !

Im sorry if I revive an old post.

I have a simmilar message on one of my server, tho it hasn't rebooted yet, and I can also say I have that on many of my server and it seems to be related to the IBM SDD Server. Multipath daemon for SAN device.

When I check my log I have a huge number of fown: signal 29, pid 12753
And the PID is "sddsrv"

I will check for the firmware update as you mentionned I hope it will help. On our end these servers run DB2 databases.

I guess your database server was running on SAN disks too?

No problem pete,

There is no thing as an old post...


yes i use sdd driver on some servers to connect to SAN,upgrading the firmware on the db servers resolved this issue.

also check that your current kernel is compatible with the sdd driver version.