How to run long-running post-receive hook script in the background on Bitbucket Server and Data Center
プラットフォームについて: Server および Data Center のみ。この記事は、Server および Data Center プラットフォームのアトラシアン製品にのみ適用されます。
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Fisheye および Crucible は除く
このページの内容はサポート対象外のプラットフォームに関連しています。したがって、アトラシアン サポートではこのページの記載内容のサポートの提供は保証されません。この資料は情報提供のみを目的として提供されています。内容はお客様自身の責任でご利用ください。
要約
This article explains how to run long-running post-receive hook script in the background on Bitbucket Server and Data Center installations.
If Bitbucket is configured to use a post-receive hook script that is calling a long-running program, this program will block the hook script, and Bitbucket will log the alert message "Slow hook script detected" to atlassian-bitbucket-alerts.log.
To ensure that Bitbucket will not wait for this long-running program to finish, it must be run as a daemon in the background.
環境
8.11, but also applicable to other versions.
ソリューション
Calling another script from the main hook script with added "&" does not work. Bitbucket still waits for all process' children to complete before considering hook execution completed.
What should be done here is to daemonize the long-running program. This can be done directly inside that program's code, but we can also do this using a small shell wrapper; the idea for this one-liner comes from https://stackoverflow.com/a/49183740:
( cd /; umask 0; setsid ${SCRIPT} </dev/null &>/dev/null & ) &SCRIPThere points to the program we want to daemonize.- It is possible to pass parameters to
SCRIPT.
The most important points that we are doing here are:
- We make a subshell using parenthesis and start that subshell in the background.
- By "setsid" we make a new process-group session.
- We close new script's STDIN, STDOUT, STDERR.
- Changing the working directory to "/" and setting umask are not important in this case; they are included here because both are considered part of good practice when daemonizing processes.