0

git を展開ツールとして使用するサーバーのセットアップがあります。bash単一のファイルをチェックアウトしてpost-receiveから実行します。

そのbashスクリプトは、実行してプロセスを停止することを想定していecho "" > fifo_fileます。

これは、誰かが SSH 経由でサーバーにログインし、手動で を呼び出した場合に完全に機能しますbash_script.sh。この場合、すべてのプロセスが停止され、コードがデプロイされ、新しいプロセスが開始されます。

しかし、 によって実行されたまったく同じシーケンスpost-receiveはまったく機能しません。古いプロセスは再起動後も生きているため、新しくデプロイされたコードが機能するために必要なポートを占有します。

そこで何が問題になる可能性がありますか？

4

2 に答える 2

0

同様の問題がありますが、最初に、問題をデバッグするためのヒントを示します。

  • プロセス階層を調べて、そこにあるべきではないプロセスがあるかどうかを確認します。ps faux

  • プロセスが何かにぶら下がっているままで、何がわからない場合はstrace -p <PID>、プロセスをブロックしているシステムコールを確認できます。

  • これがファイル記述子（読み取りまたは書き込み呼び出しでのブロック）に関するものである場合は、を使用してそのプロセスのファイル記述子を確認できます。lsof -p <PID>

  • ここで、このファイル記述子を使用している他のプロセスを確認したい場合は、NODE列の番号を確認して実行できます。lsof | grep <NODE>

私が抱えていた問題は、フックスクリプトからの標準出力と標準エラーがパイプ内のgitによってトラップされ、リモートホスト（gitプッシュを実行したホスト）に転送されることでした。また、私のスクリプトはpostgresqlデーモンを再起動しました。結果として、postgresqlはgitから標準出力と標準エラーを継承しました。つまり、すべてをリモートヒットホストに転送するパイプです。

1つの解決策は、サービスを生成する場合にstdoutとstderrを閉じることです。たとえば、次のようにします。

service postgresql restart >&- 2>&- <&-

ただし、エラーメッセージは表示されません。私が考えたもう1つのより一般的な解決策は、更新後のフックに次のコードを配置することでした。

# Creates a temp file
t="$(tempfile)" || exit
trap "rm -f -- '$t'" EXIT

# Run the script
# You need to run the script in background, and to redirect its standard and
# error output to $t
bash path/to/script.bash >"$t" 2>&1 </dev/null &

# use tail -f to follow the output of the script, and --pid to exit when the
# previous script exits ($! is the pid of the script). This might not be very
# portable though
tail -n 0 --pid $! -f "$t"

# Clean up temp file
# if a process is still attached to it, the inode won't be cleared until the
# process close the file or dies. In our case, we don't care much.
rm -f -- "$t"
trap - EXIT
于 2013-01-14T16:02:47.597 に答える
0

いくつかのステップを実行するスクリプト bash_script.sh があります。フックによってトリガーされた場合、最初のステップ (fifo ファイルへの書き込みによるプロセスの停止) は機能しないようです。

次の手順は無視して、最初の手順に集中しましょう。

ファイルシステムに fifo ファイルがあります。一方の端には、その fifo に書き込むプロセスがあります。反対側には、その fifo から読み取り、プロセスのシャットダウンをトリガーする別のプロセスがあります。

その fifo は両側をほぼ完全に分離するため、最初のプロセスのシェル モードや環境変数などの微妙な違いは、2 番目のプロセスには関係ありません。

唯一のポイントは、適切なファイルにアクセスする必要があり、そのファイルに書き込む権限が必要なことです。

いくつかのアイデア:

  • 必ず絶対パス (/ で始まる) でファイルにアクセスしてください。そうしないと、間違ったファイルに書き込む可能性があります。;)
  • fifo に適切なアクセス権があることを確認してください。-しかし、それはすでに当てはまるはずです。
  • デバッグを少し追加します。
    • 展開スクリプトはまったくトリガーされていますか?
    • あなたは何かについて文句を言いますか？
    • id;pwd;ls -ld $fifoフックのようなものを追加します。

これにより、何が起こっているかのヒントが得られるはずです。

于 2012-12-03T23:01:19.533 に答える