Kernel Panic with 028stab064.4 ? [message #37138] |
Fri, 21 August 2009 06:38 |
subigo
Messages: 7 Registered: August 2009
|
Junior Member |
|
|
Hey guys,
Here's my problem...
Basically, we have a node running on CentOS 5.3 64-bit and it has been solid forever. And then 2-3 days ago we upgraded the kernel from 028stab062.3 to 028stab064.4.
About 24-48 hours after the upgrade, the node crashed. The datacenter rebooted it and we checked the logs... nothing. So exactly 24 hours after the first crash, it happened again. I asked the datacenter to give me all of the information they had and I was told:
"Looks like a kernel panic related to a crond process, something about __posix_lock_file_conf".
A few hours later, it crashed again.
The problem is I just can't pinpoint where this is coming from. There are no oops messages, no conflicts, nothing starting right before the crash, nothing. There's simply nothing being logged when this happens.
Anyway, I know this is a long-shot, but has anyone ever experienced a problem related to "posix_lock_file_conf"? I've done the obvious and reverted to the old kernel for now, which so far has remained stable.
The node is a quad-core with 8GB ram and normally runs at about 0.10 to 0.40 with around 6GB of ram actually used.
So yeah, has anyone had any issues with this latest kernel?
|
|
|
Re: Kernel Panic with 028stab064.4 ? [message #37140 is a reply to message #37138] |
Fri, 21 August 2009 07:56 |
khorenko
Messages: 533 Registered: January 2006 Location: Moscow, Russia
|
Senior Member |
|
|
Hi.
i'm afraid you faced some new issue, so we are very interested in details on it.
Could you please configure a serial console on the node (or at least - network console)
http://wiki.openvz.org/Remote_console_setup
Unfortunately without logs we can do nothing so we have to wait next crash - please, collect the logs, take picture of the oops on the local console and file a bug in bugzilla for this issue.
Good luck!
--
Konstantin
If your problem is solved - please, report it!
It's even more important than reporting the problem itself...
|
|
|
|
|
|
|
|
|