サーバクラッシュの問題に関する調査では、以下の情報が必要となります。

1. 発生した問題、ServerProtectの使用環境に対する基本的な情報
(1) 問題は今も続いていますか。また、発生頻度はどのくらいありますか。
(2) 問題は簡単に再現できますか。
(3) 問題が再現できる場合は、その手順をお伝えください。
(4) 問題はServerProtectをインストールした全コンピュータ中の何台で起きていますか。
(5) 問題は特定のプラットフォームで起きていますか。
(6) この問題が起こる前、コンピュータは正常に動いていましたか。
(7) 問題が起こる前、システムまたはネットワークに変更を加えましたか。
(8) ServerProtectのSecurityPatchや弊社から個別に提供したHotfix（修正モジュール）を適用した経緯があれば、SecurityPatch名やHotfix名を教えてください。

2. OSの基本情報
(1) OSのバージョン情報
Red Hat Enterprise Linux の場合：
# cat /etc/redhat-release

SuSE Linux Enterprise Server / Novell Linux Desktop の場合：
# cat /etc/SuSE-release

(2) bootディレクトリの情報
# ls –al /boot

(3) カーネルのrpmパッケージ情報
# rpm –qi kernel
(カーネルパッケージが複数インストールされている場合、uname –a の結果を元に現在起動中のカーネルのrpmパッケージ情報を取得します。)
# rpm –qi kernel-2.6.9-5.EL (例)

(4) インストールディレクトリの権限
# ls –l /
# ls –l /opt

(5) コンピュータ上に存在しているカーネルフックモジュール(KHM)の情報
# cd /opt/TrendMicro/SProtectLinux/SPLX.module
# ls -al | grep splxmod

(6) KHMのチェックサム
# md5sum /opt/TrendMicro/SProtectLinux/SPLX.module/*

(7) KHMのロード状況
# lsmod | grep splxmod

(8) splxサービスの現在の状態
# /etc/init.d/splx status

(9) SPLXのビルド情報
# rpm -qa | grep splx

(10) KHMのバージョン
# modinfo /opt/TrendMicro/SProtectLinux/SPLX.module/splxmod.ko

(11) KHMの作成元について
弊社サポートセンターにご依頼いただき弊社より提供したKHMでしょうか、それともお客様独自にコンパイルされたKHMでしょうか。　


以上の情報を”GeneralInfo.txt”と言うファイル名のテキストファイルへまとめて出力してください。


(12) CDT(Case Diagnostic Tool)データの取得
# /opt/TrendMicro/SProtectLinux/SPLX.util/DiagnosticTool
Collecting product info...
Collecting system info...
Collect info success!

上記コマンド実行後、/var/log/TrendMicro/CDT_Data/ 配下にある下記のファイルを取得してください。
YYYYMMDD-hhmmss.tgz
(YYYYMMDD-hhmmss は、データを取得した日時[年月日-時分秒])
※ tgzファイルの中身は、ファイル名と同じ名前のディレクトリ内に保存されています。

3. システムのログファイル
初期設定では、/var/log/messages に記録されます。
ログローテートされたファイル(/var/log/messages.*)も含めて採取してください。

4. auditdおよびSELinuxの影響の確認
auditdまたは、selinuxの影響によって現象が発生しているかどうか確認するため、各サービスを一旦無効にしても現象が発生するかどうかお試しください。
[auditd の無効化]
# chkconfig auditd off 2345
# reboot

[SELinuxの無効化]
(1) viエディタ等で、/etc/selinux/configファイルを編集します。
初期設定では、7行目に記載されている”SELINUX=enforcing”の記述を”SELINUX=disabled”に修正し、上書き保存します。
(2)サーバを再起動します。

5. ランレベルの変更
ランレベルが5 (X Windows Systemを起動する設定)の状態で問題が発生している場合、ランレベル3で起動した時でも問題が発生するかどうかお試しください。

6. ServerProtectのデバッグログ
(1) viなどのテキストエディタで、/etc/syslog.confへ下記のエントリを追記します。
local3.debug /var/log/vsapiapp.log　(vsapiapp デバッグログ用)

(2) syslogdデーモンを再起動します。
#systemctl restart syslog

(3) SPLXサービスを停止します。
#systemctl stop splx

(4) viなどのテキストエディタで、/opt/TrendMicro/SProtectLinux/tmsplx.xmlファイルの以下の部分を編集します。
P Name="UserDebugLevel" Value="5"　(vsapiappデバッグログ用。初期設定では”1”)

(5) SPLXサービスを起動します。
systemctl start splx

(6) 問題を再現させます。

(7) 以下のファイルにデバッグログは出力されますので、これらを取得します。
/var/log/vsapiapp.log

(8) 手順(4)で書き換えたtmsplx.xmlファイルおよび、手順(1)で書き換えた/etc/syslog.confファイルを元の値に戻します。

(9) SPLXおよびsyslogdサービスを再起動し、デバッグモードを終了します。
# systemctl restartsplx restart
# systemctl restart syslog

7. カーネルのクラッシュダンプ
netdump , diskdump , kdump等のツールでクラッシュダンプを出力する設定になっている場合、カーネルパニック発生時には自動的にクラッシュダンプ(vmcoreファイル)が作成されます。現象発生時のクラッシュダンプをご提供ください。

システムハングアップの現象発生時で強制的にクラッシュダンプを出力させるには以下の方法を参考にしてください。
(以下の方法でクラッシュダンプを出力させるには、事前にnetdump , diskdump , kdump等のツールでクラッシュダンプを出力する準備が整っている必要があります。これらのツールの使用法についてはトレンドマイクロでサポートいたしかねますので、OSのサポート等へご確認ください。)

【事前準備】
vi 等のテキストエディタで、/etc/sysctl.confファイルの以下の部分を編集し、SysRqキーによる強制割り込み操作を有効にしておきます。
kernel.sysrq = 1
(初期設定では、上記の値が0になっています。)

上記の設定を有効にするため、OSを再起動します。

【システムハングアップ時の強制ダンプ採取手順】
現象発生時に[Alt]+[SysRq]+[C]を同時に押します。
この操作により、強制的にカーネルパニックを発生させ、クラッシュダンプが出力されます。

以下は情報取得手段では無く、システムを終了させる方法です。
状況によっては、以下の操作でも正常にシステムを終了できず、強制的に電源を落とす以外の手段が無い可能性もあります。
　　[Alt] + [SysRq] + [S]：すべてのマウントされているファイルシステムをsyncする。
　　[Alt] + [SysRq] + [U]：すべてのマウント済みのファイルシステムを'書き込み不可'で再マウントする。
　　[Alt] + [SysRq] + [B]：即座にシステムをリブートする。その際、ディスクのsyncやアンマウントは実行されない。

記載例）
20**/**/** 実施
10:05　xxxサーバにてシステム時計の時刻を確認
10:15　xxxサーバにて製品デバッグログの取得を開始
10:17　並行して、xxxサーバにて同時に製品デバッグログの取得を開始
10:20　現象が再現されることを確認
10:25　xxxサーバ/xxxサーバにて各データの取得