※ ChatGPTを利用し、要約された質問です(原文:ServerProtect for LinuxによるOSハングアップ)
ServerProtect for LinuxによるOSハングアップ
このQ&Aのポイント
RedhatES4を使用している場合に、ServerProtect for Linuxによって不定期にOSハングアップが発生する問題が報告されています。
ハングアップ発生時にはmessagesに特定のログが残りますが、解析にはメモリダンプの提供が必要であり、これが困難な状況です。
この問題に対する解決策は現在のところ提供されておらず、問い合わせをしてもメモリダンプの取得が求められます。
ServerProtect for LinuxによるOSハングアップ
RedhatES4を使っていますが不定期でハングアップが発生します。
サーバは2台あるのですが毎回、同じように2台ともハングアップ状態となります。
messagesには以下のようなログが残っているのですが何か分からないでしょうか?
問い合わせをしてもメモリダンプを取得しないと解析できない。の一点張りです。
メモリダンプを取るためにはOSインストール時に領域確保の必要があり不可能な状態です。
何か分かりませんでしょうか?
Apr 13 18:40:23 hostname kernel: ------------[ cut here ]------------
Apr 13 18:40:23 hostname kernel: kernel BUG at include/linux/dcache.h:282!
Apr 13 18:40:23 hostname kernel: invalid operand: 0000 [#1]
Apr 13 18:40:23 hostname kernel: SMP
Apr 13 18:40:23 hostname kernel: Modules linked in: splxmod(U) md5 ipv6 mainte(U) autofs4 i2c_dev i2c_core sunrpc dm_mirror dm_mod button battery ac uhci_hcd ehci_hcd e752x
_edac edac_mc e1000 bonding(U) floppy sg st ext3 jbd megaraid_mbox megaraid_mm aic79xx(U) sd_mod scsi_mod
Apr 13 18:40:23 hostname kernel: CPU: 0
Apr 13 18:40:23 hostname kernel: EIP: 0060:[<f8a25746>] Tainted: P VLI
Apr 13 18:40:23 hostname kernel: EFLAGS: 00010246 (2.6.9-34.0.2.ELsmp)
Apr 13 18:40:23 hostname kernel: EIP is at nonwildcard_match_inDir+0x12b/0x1ac [splxmod]
Apr 13 18:40:23 hostname kernel: eax: 00000000 ebx: f31bb344 ecx: 000000df edx: c483089c
Apr 13 18:40:23 hostname kernel: esi: 00000000 edi: 00002f9f ebp: f8a301dc esp: e4952d98
Apr 13 18:40:23 hostname kernel: ds: 007b es: 007b ss: 0068
Apr 13 18:40:23 hostname kernel: Process ps (pid: 12191, threadinfo=e4952000 task=e245ab30)
Apr 13 18:40:23 hostname kernel: Stack: c482d780 c483089c f31bb344 c482df80 00000000 c016e4c0 e4952f20 00000023
Apr 13 18:40:23 hostname kernel: 00000001 00000000 f7cc417c c482df80 00000000 00000246 00000000 00000001
Apr 13 18:40:23 hostname kernel: 00000001 00000000 00000000 0000022c c01761cd e4952fac f7546900 00000000
Apr 13 18:40:23 hostname kernel: Call Trace:
Apr 13 18:40:23 hostname kernel: [<c016e4c0>] dput+0x34/0x1a7
Apr 13 18:40:23 hostname kernel: [<c01761cd>] simple_read_from_buffer+0xa6/0xcf
Apr 13 18:40:23 hostname kernel: [<f8a25c00>] inDirs+0xa6/0xf4 [splxmod]
Apr 13 18:40:23 hostname kernel: [<f8a26557>] needToScanThisOpen+0xfc/0x216 [splxmod]
Apr 13 18:40:23 hostname kernel: [<f8a23b7b>] openHook+0x39b/0x96d [splxmod]
Apr 13 18:40:23 hostname kernel: [<c016e4c0>] dput+0x34/0x1a7
Apr 13 18:40:23 hostname kernel: [<c01c21c0>] atomic_dec_and_lock+0x20/0x40
Apr 13 18:40:23 hostname kernel: [<c0186e1c>] pid_delete_dentry+0xb/0x14
Apr 13 18:40:23 hostname kernel: [<c016e52d>] dput+0xa1/0x1a7
Apr 13 18:40:23 hostname kernel: [<f8a245fb>] closeHook+0x4ae/0x886 [splxmod]
Apr 13 18:40:23 hostname kernel: [<c01761cd>] simple_read_from_buffer+0xa6/0xcf
Apr 13 18:40:23 hostname kernel: [<c01862a0>] proc_info_read+0x65/0x6d
Apr 13 18:40:23 hostname kernel: [<c0178124>] dio_await_one+0x1d/0xb8
Apr 13 18:40:23 hostname kernel: [<c015a441>] vfs_read+0xda/0xe2
Apr 13 18:40:23 hostname kernel: [<c02d268f>] syscall_call+0x7/0xb
Apr 13 18:40:23 hostname kernel: Code: c7 b8 01 00 00 00 e9 9a 00 00 00 8b 50 14 39 d0 75 55 8b 04 24 85 c0 74 04 f0 ff 40 28 8b 54 24 04 85 d2 74 11 8b 02 85 c0 75 08 <0f>
0b 1a 01 d8 b5 a2 f8 f0 ff 02 8d 54 24 04 89 e0 e8 31 03 74
Apr 13 18:40:23 hostname kernel: ------------[ cut here ]------------
お礼
ありがとうございます。 このサーバ64bitなんです…。 もしかしたらそれが原因かもしれないですね。 動きはしているのですが。 もう少し調べてみます。 ありがとうございました。