トラブルシューティング
このページでは、PRX-SDの実行中に発生する最も一般的な問題とその原因および解決策を説明します。
シグネチャデータベースの更新失敗
症状： sd updateがネットワークエラー、タイムアウト、またはSHA-256不一致で失敗する。
考えられる原因：
- インターネット接続なし、またはファイアウォールがアウトバウンドHTTPSをブロック
- 更新サーバーが一時的に利用不可
- プロキシまたは企業ファイアウォールがレスポンスを変更している
解決策：
- 更新サーバーへの接続を確認：
curl -fsSL https://api.github.com/repos/openprx/prx-sd-signatures/commits?per_page=1- ネットワーク制限がある場合はオフライン更新スクリプトを使用：
# On a machine with internet access
./tools/update-signatures.sh
# Copy the signatures directory to the target machine
scp -r ~/.prx-sd/signatures user@target:~/.prx-sd/- 破損したキャッシュをクリアするために強制再ダウンロード：
sd update --force- プライベートミラーをホストしている場合はカスタム更新サーバーを使用：
sd config set update_server_url "https://internal-mirror.example.com/prx-sd/v1"
sd update- SHA-256不一致を確認 -- これは通常、転送中にダウンロードが破損したことを意味します。再試行するか、手動でダウンロードしてください：
sd update --forceTIP
ダウンロードせずに更新が利用可能かどうかを確認するにはsd update --check-onlyを実行してください。
スキャン速度が遅い
症状： ディレクトリのスキャンが予想よりもはるかに時間がかかる。
考えられる原因：
- ネットワークマウントファイルシステム（NFS、CIFS、SSHFS）のスキャン
- YARAルールがスキャンごとにコンパイルされている（キャッシュされたコンパイルなし）
- 多すぎるスレッドがスピニングディスク上でI/Oを競合している
- 大きなネストされたアーカイブでのアーカイブ再帰
解決策：
- SSDバックアップストレージのためにスレッド数を増やす：
sd config set scan.threads 16- スピニングディスク（I/Oバウンド）のためにスレッド数を減らす：
sd config set scan.threads 2- 遅いまたは無関係なパスを除外：
sd config set scan.exclude_paths '["/mnt/nfs", "/proc", "/sys", "/dev", "*.iso"]'- 不要な場合はアーカイブスキャンを無効化：
sd config set scan.scan_archives false- 深くネストされたアーカイブを避けるためにアーカイブ深度を制限：
sd config set scan.max_archive_depth 1- 1回限りのスキャンには**
--excludeフラグを使用**：
sd scan /home --exclude "*.iso" --exclude "node_modules"- ボトルネックを見つけるためにデバッグログを有効化：
sd --log-level debug scan /path/to/dir 2>&1 | grep -i "slow\|timeout\|skip"fanotify権限エラー
症状： sd monitor --blockが「Permission denied」または「Operation not permitted」で失敗する。
考えられる原因：
- rootとして実行していない
- Linuxカーネルに
CONFIG_FANOTIFY_ACCESS_PERMISSIONSが有効化されていない - AppArmorまたはSELinuxがfanotifyアクセスをブロックしている
解決策：
- rootとして実行：
sudo sd monitor /home /tmp --block- カーネル設定を確認：
zgrep FANOTIFY /proc/config.gz
# Should show: CONFIG_FANOTIFY=y and CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y- 非ブロックモードをフォールバックとして使用（依然として脅威を検出しますが、ファイルアクセスを防止しない）：
sd monitor /home /tmpWARNING
ブロックモードはfanotifyサポートを持つLinuxのみで利用可能です。macOS（FSEvents）とWindows（ReadDirectoryChangesW）では、リアルタイム監視は検出専用モードで動作します。
- SELinux/AppArmorを確認：
# SELinux: check for denials
ausearch -m AVC -ts recent | grep prx-sd
# AppArmor: check for denials
dmesg | grep apparmor | grep prx-sd誤検知（正当なファイルが脅威として検出される）
症状： 既知の安全なファイルがSuspiciousまたはMaliciousとしてフラグ立てされる。
解決策：
- 何がトリガーされたかを確認：
sd scan /path/to/file --jsondetection_typeとthreat_nameフィールドを確認：
HashMatch-- ファイルのハッシュが既知のマルウェアハッシュに一致する（誤検知の可能性は低い）YaraRule-- YARAルールがファイル内のパターンに一致したHeuristic-- ヒューリスティックエンジンがファイルをしきい値以上にスコアリングした
- ヒューリスティックの誤検知の場合、しきい値を上げる：
# Default is 60; raise to 70 for fewer false positives
sd config set scan.heuristic_threshold 70- スキャンからファイルまたはディレクトリを除外：
sd config set scan.exclude_paths '["/path/to/safe-file", "/opt/known-good/"]'YARAの誤検知の場合、
~/.prx-sd/yara/ディレクトリ内の特定のルールを削除またはコメントアウトすることで除外できます。ハッシュでホワイトリスト化 -- ファイルのSHA-256をローカル許可リストに追加します（将来の機能）。回避策として、パスでファイルを除外してください。
TIP
検出が本当に誤検知だと思われる場合は、ファイルハッシュ（ファイル自体ではなく）とルール名を含めてgithub.com/openprx/prx-sd/issuesで報告してください。
デーモンが起動できない
症状： sd daemonが直ちに終了する、またはsd statusが「stopped」を表示する。
考えられる原因：
- 別のインスタンスがすでに実行中（PIDファイルが存在する）
- データディレクトリにアクセスできないまたは破損している
- シグネチャデータベースが見つからない
解決策：
- 古いPIDファイルを確認：
cat ~/.prx-sd/prx-sd.pid
# If the listed PID is not running, remove the file
rm ~/.prx-sd/prx-sd.pid- デーモンのステータスを確認：
sd status- フォアグラウンドで実行してデバッグログで起動エラーを確認：
sd --log-level debug daemon /home /tmp- シグネチャが存在することを確認：
sd info
# If hash_count is 0, run:
sd update- ディレクトリ権限を確認：
ls -la ~/.prx-sd/
# All directories should be owned by your user and writable- データディレクトリが破損している場合は再初期化：
# Back up existing data
mv ~/.prx-sd ~/.prx-sd.bak
# Re-run any command to trigger first-run setup
sd info
# Re-download signatures
sd updateログレベルの調整
問題： 問題をデバッグするためにより多くの診断情報が必要。
PRX-SDは5つのログレベルをサポートします（最も詳細から最も少ない詳細順）：
| レベル | 説明 |
|---|---|
trace | ファイルごとのYARAマッチングの詳細を含むすべて |
debug | 詳細なエンジン操作、プラグインの読み込み、ハッシュルックアップ |
info | スキャン進捗、シグネチャ更新、プラグイン登録 |
warn | 警告と非致命的エラー（デフォルト） |
error | 重大なエラーのみ |
# Maximum verbosity
sd --log-level trace scan /tmp
# Debug-level for troubleshooting
sd --log-level debug monitor /home
# Redirect logs to a file for analysis
sd --log-level debug scan /home 2> /tmp/prx-sd-debug.logTIP
--log-levelフラグはグローバルであり、サブコマンドの前に来る必要があります：
# Correct
sd --log-level debug scan /tmp
# Incorrect (flag after subcommand)
sd scan /tmp --log-level debugメモリ使用量が多い
症状： sdプロセスが予想以上のメモリを消費する。特に大きなディレクトリスキャン中。
考えられる原因：
- 多くのスレッドで非常に多くのファイルをスキャンしている
- YARAルールはメモリにコンパイルされる（38,800件以上のルールは大きなメモリを使用）
- アーカイブスキャンで大きな圧縮ファイルがメモリに展開される
max_memory_mb制限が高いWASMプラグイン
解決策：
- スレッド数を減らす（各スレッドが独自のYARAコンテキストを読み込む）：
sd config set scan.threads 2- 非常に大きなファイルをスキップするために最大ファイルサイズを制限：
# Limit to 50 MiB
sd config set scan.max_file_size 52428800- メモリ制限システムのためにアーカイブスキャンを無効化：
sd config set scan.scan_archives false- アーカイブ深度を制限：
sd config set scan.max_archive_depth 1WASMプラグインのメモリ制限を確認 --
~/.prx-sd/plugins/*/plugin.jsonでmax_memory_mbの値が高いプラグインを確認して削減してください。スキャン中のメモリを監視：
# In another terminal
watch -n 1 'ps aux | grep sd | grep -v grep'- デーモンの場合、時間の経過とともにメモリを監視：
sd status
# Shows PID; use top/htop to watch memoryその他の一般的な問題
「No YARA rules found」警告
YARAルールディレクトリが空です。初回セットアップを再実行するかルールをダウンロード：
sd update
# Or manually trigger setup by removing the yara directory:
rm -rf ~/.prx-sd/yara
sd info # triggers first-run setup with embedded rules「Failed to open signature database」エラー
LMDBシグネチャデータベースが破損している可能性があります：
rm -rf ~/.prx-sd/signatures
sd updateAdblock：「insufficient privileges」
adblockの有効化/無効化コマンドはシステムホストファイルを変更するためにrootが必要です：
sudo sd adblock enable
sudo sd adblock disable「timeout」エラーでファイルがスキャンをスキップされる
個別ファイルのタイムアウトはデフォルトで30秒です。複雑なファイルのために増やしてください：
sd config set scan.timeout_per_file_ms 60000ヘルプの取得
上記の解決策で問題が解決しない場合：
- 既存のissueを確認： github.com/openprx/prx-sd/issues
- 以下を含む新しいissueを提出：
- PRX-SDバージョン（
sd info） - オペレーティングシステムとカーネルバージョン
- デバッグログ出力（
sd --log-level debug ...） - 再現手順
- PRX-SDバージョン（