strace を使用したソフトウェア展開のデバッグ

私の本業は主にソフトウェアのデプロイメントなので、次のような質問に答えるのに多くの時間を費やしています。

• このソフトウェアは開発者にとっては機能しますが、私にとっては機能しません。 なぜ？
• 昨日はこのソフトウェアはうまくいきましたが、今日はうまくいきません。 なぜ？

これは、通常のソフトウェア デバッグとは少し異なる種類のデバッグです。 通常のデバッグはコードのロジックに関するものですが、展開デバッグはコードと環境の間の相互作用に関するものです。 問題の根本が論理エラーだったとしても、あるマシンではすべてが機能し、別のマシンでは機能しないという事実は、問題が何らかの形で環境にあることを意味します。

したがって、次のような通常のデバッグツールの代わりに GDB デプロイメントをデバッグするための別のツール セットがあります。 そして、「なぜこのソフトウェアが動作しないのですか?」という問題に対処するための私のお気に入りのツールです。 呼ばれた ストラス.

ステレースとは何ですか？

ストラス 「システムコールトレース」のためのツールです。 元々は Linux 用に作成されましたが、同じデバッグ トリックは他のシステムのツールでも実行できます (DTrace または ktrace).

基本的なアプリケーションは非常にシンプルです。 任意のコマンドで strace を実行するだけで、すべてのシステム コールがダンプされます (ただし、最初に自分でインストールする必要があるかもしれません) ストラス):

$ strace echo Hello
...Snip lots of stuff...
write(1, "Hellon", 6)                  = 6
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

これらのシステムコールは何ですか? これは、オペレーティング システム カーネルの API のようなものです。 かつて、ソフトウェアはそれが実行されるハードウェアに直接アクセスできました。 たとえば、画面に何かを表示する必要がある場合、ビデオ デバイスのポートまたはメモリ マップされたレジスタを操作します。 マルチタスクのコンピュータ システムが普及すると、さまざまなアプリケーションがハードウェアをめぐって争奪戦が発生し、混乱が生じました。 XNUMX つのアプリケーションでエラーが発生すると、システム全体ではないにしても、他のアプリケーションがダウンする可能性があります。 その後、特権モード (または「リング保護」) が CPU に登場しました。 カーネルが最も特権を持つようになりました。カーネルはハードウェアへの完全なアクセス権を受け取り、システム コールを通じてハードウェアと対話するためにカーネルにアクセスを要求する必要があった、より特権の低いアプリケーションを生成しました。

バイナリ レベルでは、システム コールは単純な関数呼び出しとは少し異なりますが、ほとんどのプログラムは標準ライブラリのラッパーを使用します。 それらの。 POSIX C 標準ライブラリには関数呼び出しが含まれています 書く（）、システムコールのアーキテクチャ固有のコードがすべて含まれています。 書きます.

つまり、アプリケーションとその環境 (コンピューター システム) 間の対話はシステム コールを通じて実行されます。 したがって、ソフトウェアがあるマシンでは動作するが、別のマシンでは動作しない場合は、システム コールのトレース結果を確認するとよいでしょう。 より具体的には、システム コール トレースを使用して分析できる典型的な瞬間のリストを次に示します。

• コンソール I/O
• ネットワークI/O
• ファイル システム アクセスとファイル I/O
• プロセススレッドの存続期間の管理
• 低レベルのメモリ管理
• 特定のデバイスドライバーへのアクセス

strace をいつ使用するか?

理論的には、 ストラス ユーザー空間のプログラムはシステムコールを行う必要があるため、ユーザー空間のプログラムで使用されます。 コンパイル済みの低レベル プログラムでより効率的に動作しますが、ランタイムやインタープリタからの追加ノイズをカットできれば、Python などの高レベル言語でも動作します。

すべての素晴らしさで ストラス あるマシンでは正常に動作するソフトウェアのデバッグ中に現れますが、別のマシンでは突然動作を停止し、ファイル、権限、またはコマンドやその他の何かを実行しようとして失敗したことに関するあいまいなメッセージが表示されます。残念ですが、そうではありません。証明書検証エラーなどの高レベルの問題とうまく組み合わせることができます。 通常、これには組み合わせが必要です ストラス時々 追跡する およびより高いレベルのツール (コマンド ライン ツールなど) opensslの 証明書をデバッグするため)。

例としてスタンドアロン サーバーを使用しますが、システム コール トレースは多くの場合、より複雑な展開プラットフォームでも実行できます。 必要なのは、適切なツールを選択することだけです。

簡単なデバッグ例

素晴らしいサーバー アプリケーション foo を実行すると、最終的に次の結果が得られるとします。

$ foo
Error opening configuration file: No such file or directory

どうやら、あなたが書いた設定ファイルが見つからなかったようです。 これは、パッケージ マネージャーがアプリケーションをコンパイルするときに、予期されるファイルの場所をオーバーライドする場合があるために発生します。 また、あるディストリビューションのインストール ガイドに従っていると、別のディストリビューションでは、予想していた場所とはまったく異なるファイルが見つかります。 エラー メッセージに設定ファイルの場所が示されていれば問題は数秒で解決できますが、そうではありません。 では、どこを見ればいいのでしょうか？

ソースコードにアクセスできれば、それを読んですべてを知ることができます。 優れたバックアップ計画ですが、最速のソリューションではありません。 次のようなステップバイステップのデバッガに頼ることができます GDB プログラムの動作を確認しますが、環境との対話を示すために特別に設計されたツールを使用する方がはるかに効果的です。 ストラス.

出力 ストラス 冗長に思えるかもしれませんが、幸いなことに、そのほとんどは無視しても問題ありません。 多くの場合、-o 演算子を使用してトレース結果を別のファイルに保存すると便利です。

$ strace -o /tmp/trace foo
Error opening configuration file: No such file or directory
$ cat /tmp/trace
execve("foo", ["foo"], 0x7ffce98dc010 /* 16 vars */) = 0
brk(NULL)                               = 0x56363b3fb000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=25186, ...}) = 0
mmap(NULL, 25186, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f2f12cf1000
close(3)                                = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "177ELF2113 3 > 1 260A2 "..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1824496, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2f12cef000
mmap(NULL, 1837056, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f2f12b2e000
mprotect(0x7f2f12b50000, 1658880, PROT_NONE) = 0
mmap(0x7f2f12b50000, 1343488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7f2f12b50000
mmap(0x7f2f12c98000, 311296, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16a000) = 0x7f2f12c98000
mmap(0x7f2f12ce5000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b6000) = 0x7f2f12ce5000
mmap(0x7f2f12ceb000, 14336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f2f12ceb000
close(3)                                = 0
arch_prctl(ARCH_SET_FS, 0x7f2f12cf0500) = 0
mprotect(0x7f2f12ce5000, 16384, PROT_READ) = 0
mprotect(0x56363b08b000, 4096, PROT_READ) = 0
mprotect(0x7f2f12d1f000, 4096, PROT_READ) = 0
munmap(0x7f2f12cf1000, 25186)           = 0
openat(AT_FDCWD, "/etc/foo/config.json", O_RDONLY) = -1 ENOENT (No such file or directory)
dup(2)                                  = 3
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR)
brk(NULL)                               = 0x56363b3fb000
brk(0x56363b41c000)                     = 0x56363b41c000
fstat(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x8), ...}) = 0
write(3, "Error opening configuration file"..., 60) = 60
close(3)                                = 0
exit_group(1)                           = ?
+++ exited with 1 +++

出力の最初のページのほぼ全体 ストラス - これは通常、起動のための低レベルの準備です。 (電話が多い mmap, mプロテクト, BRK 低レベルのメモリの検出や動的ライブラリの表示などに使用されます。)実際には、出力のデバッグ中に ストラス 最後から読んだほうがいいですよ。 以下にチャレンジがあります 書きます、エラー メッセージが表示されます。 上を見ると、最初の誤ったシステム コール、つまり呼び出しがわかります。 開く、エラーがスローされます エノエント (「ファイルまたはディレクトリが見つかりません」) を開こうとしています /etc/foo/config.json。 ここに設定ファイルがあるはずです。

これはほんの一例ですが、私が使用する時間の 90% は ストラス、これほど難しいことはありません。 以下は完全なステップバイステップのデバッグ ガイドです。

• プログラムからのシステム y エラーに関するあいまいなメッセージのために動揺する
• 次のコマンドでプログラムを再起動します ストラス
• トレース結果でエラー メッセージを見つける
• 最初に失敗したシステム コールに到達するまでさらに上に進みます

ステップ 4 のシステム コールによって、何が問題だったのかが明らかになる可能性が非常に高くなります。

ヒント

より複雑なデバッグの例を示す前に、効果的に使用するためのいくつかのトリックを示します。 ストラス:

男はあなたの友達です

多くの *nix システムでは、次のコマンドを実行すると、カーネルへのシステム コールの完全なリストを取得できます。 男のシステムコール。 次のようなものが表示されます ブレーキ(2)を実行すると、より多くの情報を取得できることを意味します。 男2の休憩所.

小さな熊手: マン2フォーク シェルのページを表示します フォーク（） в GNU libc、これは呼び出しを使用して実装されていることがわかります。 クローン（）。 呼び出しセマンティクス フォーク を使用してプログラムを書いても、同じままです フォーク（）、トレースを実行します - 呼び出しは見つかりません フォーク、それらの代わりに、 クローン（）。 このような rake は、ソースと出力を比較し始めると混乱するだけです。 ストラス.

-o を使用して出力をファイルに保存します

ストラス は大量の出力を生成する可能性があるため、(上記の例のように) トレース結果を別のファイルに保存すると便利なことがよくあります。 これは、プログラム出力と出力の混同を避けるのにも役立ちます。 ストラス コンソールで。

さらに多くの引数データを表示するには、-s を使用します

上のトレース例では、エラー メッセージの後半が表示されていないことに気づいたかもしれません。 その理由は ストラス デフォルトでは、文字列引数の最初の 32 バイトのみが表示されます。 もっと見たい場合は、次のようなものを追加してください -s 128 呼び出しに ストラス.

-y を使用すると、ファイルやソケットなどを追跡しやすくなります。

「すべてがファイルである」とは、*nix システムが、ファイル、ネットワーク、またはプロセス間パイプに適用されるかどうかに関係なく、ファイル記述子を使用してすべての I/O を実行することを意味します。 これはプログラミングには便利ですが、一般的なものを見ると実際に何が起こっているかを追跡するのが難しくなります。 read и 書きます システムコールトレース結果に表示されます。

演算子を追加することで うん、強制します ストラス 出力内の各ファイル記述子に、それが指す内容の注釈を付けます。

-p** を使用して、すでに実行中のプロセスにアタッチします。

以下の例からわかるように、すでに実行中のプログラムをトレースする必要がある場合があります。 プロセス 1337 として実行されていることがわかっている場合 (たとえば、出力から) ps)、次のように追跡できます。

$ strace -p 1337
...system call trace output...

root 権限が必要な場合があります。

子プロセスを監視するには -f を使用します

ストラス デフォルトでは、XNUMX つのプロセスのみをトレースします。 このプロセスが子プロセスを生成する場合、子プロセスを生成するシステム コールは表示されますが、子プロセスのシステム コールは表示されません。

エラーが子プロセスにあると思われる場合は、次のステートメントを使用します。 -f、これによりトレースが有効になります。 この欠点は、出力がさらに混乱することです。 いつ ストラス XNUMX つのプロセスまたは XNUMX つのスレッドをトレースすると、呼び出しイベントの単一のストリームが表示されます。 複数のプロセスを同時にトレースすると、通話の開始がメッセージによって中断される場合があります。 、その後 - 他の実行ブランチに対する一連の呼び出し、そしてその後のみ - 最初の実行ブランチの終了 <…愚痴再開>。 または、これも演算子を使用して、すべてのトレース結果を異なるファイルに分割します。 -ff (詳細は ガイド 上の ストラス).

-e を使用してトレースをフィルタリングする

ご覧のとおり、トレースの結果は、考えられるすべてのシステム コールの実際の山です。 フラグ -e トレースをフィルタリングできます (「 руководство 上の ストラス）。 主な利点は、完全なトレースを実行してから実行するよりも、フィルターされたトレースを実行する方が高速であることです。 grep「で。」 正直に言うと、私はほとんど気にしていません。

すべての間違いが悪いわけではない

シンプルで一般的な例は、実行可能ファイルを含むディレクトリを探すシェルのように、一度に複数の場所でファイルを探すプログラムです。

$ strace sh -c uname
...
stat("/home/user/bin/uname", 0x7ffceb817820) = -1 ENOENT (No such file or directory)
stat("/usr/local/bin/uname", 0x7ffceb817820) = -1 ENOENT (No such file or directory)
stat("/usr/bin/uname", {st_mode=S_IFREG|0755, st_size=39584, ...}) = 0
...

「エラーを報告する前の最後に失敗したリクエスト」などのヒューリスティックは、関連するエラーを見つけるのに適しています。 いずれにしても、最後から始めるのが合理的です。

C プログラミングのチュートリアルは、システム コールを理解するのに役立ちます。

C ライブラリへの標準呼び出しはシステム コールではなく、薄い表面層にすぎません。 したがって、C でどのように何を行うかを少しでも理解すると、システムコールトレースの結果を理解しやすくなります。 たとえば、ネットワーク システムへの呼び出しのデバッグに問題がある場合は、同じ古典的なコードを見てください。 Bija のネットワーク プログラミング ガイド.

より複雑なデバッグの例

単純なデバッグの例は、作業中に主に対処しなければならないものの例であるとすでに述べました。 ストラス。 ただし、場合によっては実際の調査が必要になるため、より高度なデバッグの実例を次に示します。

ブクロン - タスク処理スケジューラ、*nix デーモンの別の実装 cron。 これはサーバーにインストールされていますが、誰かがスケジュールを編集しようとすると、次のようなことが起こります。

# crontab -e -u logs
bcrontab: Fatal: Could not create temporary file

わかりました、つまり ブクロン 彼は特定のファイルを書き込もうとしましたが、うまくいきませんでした。彼はその理由を認めませんでした。 明らかにする ストラス:

# strace -o /tmp/trace crontab -e -u logs
bcrontab: Fatal: Could not create temporary file
# cat /tmp/trace
...
openat(AT_FDCWD, "bcrontab.14779.1573691864.847933", O_RDONLY) = 3
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f82049b4000
read(3, "#Ansible: logsaggn20 14 * * * lo"..., 8192) = 150
read(3, "", 8192)                       = 0
munmap(0x7f82049b4000, 8192)            = 0
close(3)                                = 0
socket(AF_UNIX, SOCK_STREAM, 0)         = 3
connect(3, {sa_family=AF_UNIX, sun_path="/var/run/bcron-spool"}, 110) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f82049b4000
write(3, "156:Slogs #Ansible: logsaggn20 1"..., 161) = 161
read(3, "32:ZCould not create temporary f"..., 8192) = 36
munmap(0x7f82049b4000, 8192)            = 0
close(3)                                = 0
write(2, "bcrontab: Fatal: Could not creat"..., 49) = 49
unlink("bcrontab.14779.1573691864.847933") = 0
exit_group(111)                         = ?
+++ exited with 111 +++

最後の近くにエラーメッセージがあります 書きます、しかし今回は何かが違います。 まず、通常はこの前に発生する、関連するシステム コール エラーがありません。 次に、どこかで誰かがすでにエラー メッセージを読んでいることは明らかです。 本当の問題は別のところにあるようですが、 ブロンタブ 単にメッセージを再生するだけです。

見れば 男2は読んだ最初の引数 (3) がファイル記述子であり、*nix がすべての I/O 処理に使用することがわかります。 ファイル記述子 3 が何を表しているかを確認するにはどうすればよいですか? この特定のケースでは、次を実行できます ストラス 調査結果 うん (上記を参照) 自動的に教えてくれますが、このようなことを理解するには、トレース結果を読み取り、解析する方法を知っておくと役立ちます。

ファイル記述子のソースは、多くのシステム コールの 3 つである可能性があります (すべては記述子の目的 (コンソール、ネットワーク ソケット、ファイル自体、またはその他のもの) によって異なります)。 3 を返すことで呼び出します (つまり、トレース結果で「= 2」を探します)。 この結果には、そのうちの XNUMX つがあります。 開く 一番上と ソケット 途中で。 開く ファイルは開きますが、 閉じる(3) は再び閉じることを示します。 (Rake: ファイル記述子は、開いたり閉じたりするときに再利用できます)。 電話 ソケット（） 前の最後なので適切です 読んだ（）、そして、bcrontab はソケットを介して何かを操作することがわかりました。 次の行は、ファイル記述子が関連付けられていることを示しています。 UNIXドメインソケット 途中で /var/run/bcron-spool.

したがって、次のプロセスに関連するプロセスを見つける必要があります。 UNIXソケット 反対側にあります。 この目的にはいくつかの巧妙なトリックがあり、どちらもサーバーのデプロイメントをデバッグするのに役立ちます。 XNUMXつ目は、使用することです netstat またはそれより新しい ss (ソケットのステータス)。 どちらのコマンドもシステムのアクティブなネットワーク接続を表示し、次のステートメントを取得します。 -l リッスンしているソケットとオペレーターについて説明します。 -p クライアントとしてソケットに接続されているプログラムを表示します。 (他にも便利なオプションはたくさんありますが、このタスクにはこれら XNUMX つで十分です。)

# ss -pl | grep /var/run/bcron-spool
u_str LISTEN 0   128   /var/run/bcron-spool 1466637   * 0   users:(("unixserver",pid=20629,fd=3))

これは、リスナーがコマンドであることを示唆しています。 inixサーバー、プロセス ID 20629 で実行されます。 (そして、偶然にも、ファイル記述子 3 をソケットとして使用します。)

同じ情報を見つけるための XNUMX 番目の非常に便利なツールは、 lsof。 システム上で開いているすべてのファイル (またはファイル記述子) がリストされます。 または、XNUMX つの特定のファイルに関する情報を取得することもできます。

# lsof /var/run/bcron-spool
COMMAND   PID   USER  FD  TYPE  DEVICE              SIZE/OFF  NODE    NAME
unixserve 20629 cron  3u  unix  0x000000005ac4bd83  0t0       1466637 /var/run/bcron-spool type=STREAM

プロセス 20629 は存続期間の長いサーバーなので、次のサーバーに接続できます。 ストラス のようなものを使用して strace -o /tmp/trace -p 20629。 別の端末で cron ジョブを編集すると、エラーのあるトレース出力が表示されます。 そして結果は次のとおりです。

accept(3, NULL, NULL)                   = 4
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7faa47c44810) = 21181
close(4)                                = 0
accept(3, NULL, NULL)                   = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21181, si_uid=998, si_status=0, si_utime=0, si_stime=0} ---
wait4(0, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG|WSTOPPED, NULL) = 21181
wait4(0, 0x7ffe6bc36764, WNOHANG|WSTOPPED, NULL) = -1 ECHILD (No child processes)
rt_sigaction(SIGCHLD, {sa_handler=0x55d244bdb690, sa_mask=[CHLD], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7faa47ab9840}, {sa_handler=0x55d244bdb690, sa_mask=[CHLD], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7faa47ab9840}, 8) = 0
rt_sigreturn({mask=[]})                 = 43
accept(3, NULL, NULL)                   = 4
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7faa47c44810) = 21200
close(4)                                = 0
accept(3, NULL, NULL)                   = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21200, si_uid=998, si_status=111, si_utime=0, si_stime=0} ---
wait4(0, [{WIFEXITED(s) && WEXITSTATUS(s) == 111}], WNOHANG|WSTOPPED, NULL) = 21200
wait4(0, 0x7ffe6bc36764, WNOHANG|WSTOPPED, NULL) = -1 ECHILD (No child processes)
rt_sigaction(SIGCHLD, {sa_handler=0x55d244bdb690, sa_mask=[CHLD], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7faa47ab9840}, {sa_handler=0x55d244bdb690, sa_mask=[CHLD], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7faa47ab9840}, 8) = 0
rt_sigreturn({mask=[]})                 = 43
accept(3, NULL, NULL

（最後 accept（） トレース時には完了しません。) 繰り返しになりますが、残念ながら、この結果には探しているエラーが含まれていません。 bcrontag がソケットとの間で送受信するメッセージは表示されません。 代わりに、完全なプロセス制御 ( , 待つ4, シグヒルド など) このプロセスは、ご想像のとおり、実際の作業を行う子プロセスを生成します。 彼女の足跡を追跡する必要がある場合は、通話に追加してください strace -f。 これは、strace を使用して新しい結果でエラー メッセージを検索すると見つかるものです。 -f -o /tmp/trace -p 20629:

21470 openat(AT_FDCWD, "tmp/spool.21470.1573692319.854640", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied) 
21470 write(1, "32:ZCould not create temporary f"..., 36) = 36
21470 write(2, "bcron-spool[21470]: Fatal: logs:"..., 84) = 84
21470 unlink("tmp/spool.21470.1573692319.854640") = -1 ENOENT (No such file or directory)
21470 exit_group(111)                   = ?
21470 +++ exited with 111 +++

さて、それは何かです。 プロセス 21470 は、パスにファイルを作成しようとすると「アクセスが拒否されました」エラーを受け取ります tmp/spool.21470.1573692319.854640 (現在の作業ディレクトリに関連します)。 現在の作業ディレクトリだけがわかれば、フルパスもわかり、プロセスがそのディレクトリに一時ファイルを作成できない理由を理解できるでしょう。 残念ながら、プロセスはすでに終了しているため、単に使用することはできません lsof -p 21470 現在のディレクトリを見つけるためですが、逆の方向に作業することもできます。つまり、ディレクトリを変更する PID 21470 システム コールを探します。 (何もない場合、PID 21470 は親からそれらを継承している必要があり、これはすでに完了しています。 lsof -p はわかりません。） このシステムコールは、 Chdir (最新のオンライン検索エンジンを使えば簡単に見つけることができます)。 そして、これは、サーバー PID 20629 までのトレース結果に基づく逆検索の結果です。

20629 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7faa47c44810) = 21470
...
21470 execve("/usr/sbin/bcron-spool", ["bcron-spool"], 0x55d2460807e0 /* 27 vars */) = 0
...
21470 chdir("/var/spool/cron")          = 0
...
21470 openat(AT_FDCWD, "tmp/spool.21470.1573692319.854640", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied) 
21470 write(1, "32:ZCould not create temporary f"..., 36) = 36
21470 write(2, "bcron-spool[21470]: Fatal: logs:"..., 84) = 84
21470 unlink("tmp/spool.21470.1573692319.854640") = -1 ENOENT (No such file or directory)
21470 exit_group(111)                   = ?
21470 +++ exited with 111 +++

(迷ったら前回の記事を読んでみてください *nix プロセス管理とシェルについて.) したがって、サーバー PID 20629 は、次のパスにファイルを作成する許可を受け取りませんでした。 /var/スプール/cron/tmp/spool.21470.1573692319.854640。 おそらく、この原因は従来のファイル システムのアクセス許可設定にあります。 確認しよう：

# ls -ld /var/spool/cron/tmp/
drwxr-xr-x 2 root root 4096 Nov  6 05:33 /var/spool/cron/tmp/
# ps u -p 20629
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
cron     20629  0.0  0.0   2276   752 ?        Ss   Nov14   0:00 unixserver -U /var/run/bcron-spool -- bcron-spool

そこが犬が埋葬されている場所です！ サーバーはユーザー cron として実行されますが、ディレクトリへの書き込み権限を持つのは root だけです /var/スプール/cron/tmp/。 簡単なコマンド chown cron /var/spool/cron/tmp/ 作る予定です ブクロン 正しく動作します。 (それが問題ではない場合、次に疑わしいのは SELinux や AppArmor などのカーネル セキュリティ モジュールです。そのため、次のようにしてカーネル メッセージ ログを確認します。 dmesg.)

合計で

システム コール トレースは初心者にとっては圧倒されるかもしれませんが、一般的なデプロイメントの問題のクラス全体をデバッグする簡単な方法であることを示していただければ幸いです。 マルチプロセスをデバッグしようとしているところを想像してください。 ブクロンステップバイステップデバッガーを使用します。

トレース結果をシステム コール チェーンに沿って逆方向に解析するにはスキルが必要ですが、前述したように、ほとんどの場合、 ストラス, トレース結果を取得して、最後からエラーを探していくだけです。 ともかく、 ストラス デバッグにかかる​​時間を大幅に節約できます。 あなたにも役立つことを願っています。

出所： habr.com