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

私の日常業務は主にソフトウェア システムの導入です。つまり、次のような質問に答えるのに多くの時間を費やしています。

• 開発者はこのソフトウェアを動作させていますが、私の場合は動作させていません。なぜ？
• 昨日はこのソフトウェアは動作しましたが、今日は動作しません。なぜ？

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

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

straceとは何ですか?

ストラス —は「システムコールトレース」のためのツールです。元々は 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 のようなものです。昔は、ソフトウェアはそれが実行されるハードウェアに直接アクセスしていました。たとえば、画面に何かを表示する必要がある場合、ビデオ デバイスのポートやメモリ マップ レジスタを操作します。マルチタスク コンピュータ システムが普及すると、さまざまなアプリケーションがハードウェアを奪い合うようになり、混乱が生じました。 1 つのアプリケーションにバグがあると、システム全体ではなくとも、他のアプリケーションがダウンする可能性があります。その後、CPU に特権モード (または「リング保護」) が登場しました。カーネルは最も特権を持つようになりました。つまり、ハードウェアへの完全なアクセス権を取得し、システム コールを通じてハードウェアと対話するためにカーネルにアクセスを要求する必要のある、権限の低いアプリケーションが生成されました。

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

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

• コンソール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 低レベルのメモリ検出や動的ライブラリマッピングなどの機能があります。実際、デバッグ時には、出力 ストラス 最後から読むのが良いでしょう。下記に電話がかかってきます 書きます、エラーメッセージが表示されます。上を見ると、最初のエラーのあるシステムコールがわかります。 開く、エラーが発生します エノエント （「ファイルまたはディレクトリが見つかりません」）開こうとしています config.json は、。ここに構成ファイルを置く必要があります。

これは単なる例ですが、私は90％の確率で ストラス、これより難しいことは何もありません。以下は完全なステップバイステップのデバッグ ガイドです。

• プログラムからの曖昧なシステムエラーメッセージにイライラ
• プログラムを再起動する ストラス
• トレース結果でエラーメッセージを見つける
• 最初の失敗したシステムコールに到達するまで、さらに上に進みます

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

ヒント

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

男はあなたの友達です

多くの*nixシステムでは、カーネルへのシステムコールの完全なリストは、以下を実行することで取得できます。 man システムコール。次のようなものが見られます ブレーキ(2)を実行することでより多くの情報を得ることができます。 男2BRK.

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

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

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

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

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

- ファイルやソケットなどの追跡が容易になります。

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

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

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

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

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

ルートアクセスが必要になる場合があります。

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

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

エラーが子プロセスにあると思われる場合は、演算子を使用します。 -fこれにより、トレースが可能になります。この方法の欠点は、結論があなたをさらに混乱させるだけだということです。いつ ストラス 単一のプロセスまたはスレッドをトレースすると、呼び出しイベントの単一のフローが表示されます。複数のプロセスを一度にトレースすると、メッセージによって通話の開始が中断されることがあります。 、その後、他の実行ブランチへの呼び出しが続き、最初のブランチの終了が行われます。 <… foocall が再開されました>。または、演算子を使用してすべてのトレース結果を別のファイルに分割することもできます。 -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 で何をどのように行うかを少しでも理解していれば、システム コール トレースの結果を理解しやすくなります。例えば、ネットワークシステムへの呼び出しのデバッグに問題がある場合は、同じ古典的な 「ネットワークプログラミングガイド」Bij著.

より複雑なデバッグの例

すでに述べたように、この簡単なデバッグの例は、私が作業する際に主に対処しなければならない例です。 ストラス。ただし、実際の調査が必要になる場合もあるため、ここではもう少し複雑なデバッグの実際の例を示します。

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

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

では、 bcron 特定のファイルを書き込もうとしたが、うまくいかなかったが、その理由を認めようとしない。開梱してみましょう ストラス:

# 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 つあります。 開く 一番上に ソケット 途中で。 開く ファイルを開くが 閉じる（３）その後、再び閉じていることが表示されます。 (Rake: ファイル記述子は、開いたり閉じたりするときに再利用できます。) ソケット（） 最後のものなのでぴったりです 読んだ（）そして、bcrontab はソケットを介して何かと連携することがわかりました。次の行は、ファイル記述子が UNIXドメインソケット 途中で /var/run/bcron-spool.

そこで、私たちは、 UNIXソケット 反対側に。この目的には、いくつかの巧妙なトリックがあり、どちらもサーバーの展開のデバッグに役立ちます。 1つ目は netstat またはそれ以降 ss (ソケットステータス)。どちらのコマンドもシステムのアクティブなネットワーク接続を表示し、オペレータ -l リスニングソケットとオペレータを記述する -p ソケットにクライアントとして接続されているプログラムを表示します。 (他にも便利なオプションはたくさんありますが、このタスクにはこれら 2 つで十分です。)

# 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 をソケットとして使用しています。)

同じ情報を見つけるのに本当に便利な2番目のツールは lsof。システム上で開いているすべてのファイル (またはファイル記述子) を一覧表示します。または、特定のファイルに関する情報を取得することもできます。

# 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/トレース -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/スプール.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/spool/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/spool/cron/tmp/。シンプルなコマンド chown cron /var/spool/cron/tmp/ 作る予定です bcron 正常に動作します。（これが問題でない場合、次に疑われるのは SE カーネル セキュリティ モジュールです。）Linux またはAppArmorなので、カーネルメッセージログを確認します。 dmesg.)

合計で

初心者にとって、システム コール トレースの出力は圧倒的なものになる可能性がありますが、一般的なデプロイメントの問題全体をデバッグするための簡単な方法であることを示せたと思います。マルチプロセスのデバッグを想像してみてください bcronステップバイステップのデバッガーを使用します。

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

出所： habr.com