【Shell-Tips】多重起動の禁止処理を実装しよう。

特定用途のスクリプト実装後、クーロンにより毎日決まった時間に処理が実行されることを期待していたが「いつの間にかプロセスが落ちていた・・」

しかも「何時？プロセスが落ちたのか分からない」など、異常に気づいたころには「実は数ヶ月前から処理が止まっていた。」などはよくある話です。

大抵の場合、原因は多重起動処理の禁止ロジックを実装していないがために起こる悲劇です。

この問題を回避するべく「多重起動処理」を禁止にする仕組みを実装します。

多重起動禁止処理の作成

定期的に実行するスクリプトが何らかの原因により、正常に実行できずに止まってしまう（キューイング）場合、（翌日の定時などに）後から起動された同一スクリプトのプロセスは次々にOSにキューイングされて行きます。

当然キューイングされたプロセス数分のリソースが消費され、やがてリソース不足に陥りシステムがダウンしてしまいます。

上記３つの機能を実装して、多重起動処理検知時に当該プロセスを停止します。

前提となる実行環境

Beエンジニアでシェルスクリプトを実行する環境は下記の通りとします。

本処理の仕組みは、共通で使用することを前提に共通関数定義ファイル「utils.shrc」へ実装します。

Beエンジニア

【Shellの基礎知識】共通関数定義クラスの完全ガイド！設計から実践まで徹底解説

https://www.pmi-sfbac.org/shell-utils

共通関数定義クラスの概要と役割共通関数定義クラス（utils.shrc）は、シェルスクリプト開発において頻繁に使用される汎用的な関数をまとめたスクリプトです。これを活用することで、スクリプトごとに重複したコードを書く必要がなくなり、開発の効率化や保守性の向上を実現できます。特に、シェルスクリプトはプロジェクトが大規模になるにつれて管理が複雑になりがちです。utils.shrcを導入することで、スクリプト間の一貫性を保ちつつ、共通機能を統一した形式で提供できます。共通関数定義クラスの目的共通関数定義クラスの主な目...

ロック機能

スクリプトが起動した時点で「/tmp」ディレクトリ配下へ「スクリプト名.lock」ディレクトリを作成し、当該スクリプトが実行中であることを後続の同一スクリプトへ知らせるためのファイル「pid」ファイルを作成します。

[<BASE_DIR>/scripts/bin/utils.shrc ]

# --------------------------------------------------
# Acquire process lock using a lock file
# --------------------------------------------------
# Purpose:
#   Prevent multiple instances of the script from running simultaneously.
# Arguments:
#   None
# Returns:
#   0: Success (lock acquired)
#   !0: Failure (another instance is already running)
# Notes:
#   - Uses a lock file instead of a directory.
#   - Relies on `flock` for safe locking.
#   - Writes the process ID to the lock file.
# --------------------------------------------------
acquireLock() {
  LOCK_FILE="${TMP_PATH}/${SCRIPT_NAME%.*}.lock"
  exec 200>"$LOCK_FILE"  # File descriptor 200 をロックファイルに関連付け
  
  # flock コマンドを使用してロックを試みる
  if flock -n 200; then
    echo $$ > "$LOCK_FILE"  # プロセスIDを書き込む
    logOut "INFO" "Lock acquired on [$LOCK_FILE]."
    export LOCK_FILE
    return 0
  else
    logOut "ERROR" "Another instance is already running. Lock file [$LOCK_FILE] exists."
    abort
  fi
}

アンロック機能

当該スクリプトが終了した時点で「/tmp」ディレクトリ配下の「スクリプト名.lock」ディレクトリを削除します。

[<BASE_DIR>/scripts/bin/utils.shrc ]

# --------------------------------------------------
# Release the acquired lock
# --------------------------------------------------
# Purpose: # Removes the lock file to allow other instances to run.
# Arguments: # None # Returns: # None # Notes:
# - This function should be called before exiting the script. # - I
t verifies the lock file exists before removing.
# --------------------------------------------------
releaseLock() {
  if [ -n "$LOCK_FILE" ]; then
    locker=$(cat "$LOCK_FILE" 2>/dev/null)
    
    if [ "$locker" = "$$" ]; then
      rm -f "$LOCK_FILE"
      logOut "INFO" "Lock released: [$LOCK_FILE]"
    else
      logOut "WARN" "Lock file exists, but owned by PID [$locker], not [$$]."
      logOut "WARN" "Lock file [$LOCK_FILE] is left untouched."
      abort
    fi
  fi
}

処理の中断機能

既に、同一スクリプトが実行中である場合、後発の同一スクリプト処理を中断します。

[<BASE_DIR>/scripts/bin/utils.shrc ]

# --------------------------------------------------
# Abort script execution with an error message.
# --------------------------------------------------
# Purpose:
#   Logs an abort message and terminates the script with exit code 1.
# Arguments:
#   param1-: Error message to log.
#      Example: "Critical failure in configuration loading."
# Returns:
#   None (terminates script with exit code 1)
# Notes:
#   - All output is sent to standard error (stderr).
#   - Includes stack trace information for easier debugging.
# --------------------------------------------------
abort() {
  local caller_info log_msg
  caller_info=$(caller 0 2>/dev/null)  # どこで呼ばれたか取得
  
  log_msg="ABORT [$caller_info]: $*"  # `formatLog` の代わりに直接メッセージ生成
  echo "$log_msg" 1>&2  # stderr にログ出力
  
  sync  # ログを確実にディスクに書き込む
  exit 1  # スクリプトを異常終了
}

１呼び出し側のシェルスクリプト作成

実行ファイルへ多重起動禁止処理を実装し、実行後30秒間のスリープ処理を記述します。同一スクリプトを時間差で実行します。つまり後発スクリプトが先発スクリプト追い越すことを禁止します。

なお、ログの出力には下記の共通ログ出力クラスを使用しています。

Beエンジニア

1 Pocket

【Shellの基礎知識】簡単なログ出力ロジックを作ってみました。

https://www.pmi-sfbac.org/append_log

商用プロジェクトは1から100に至るまで、すべてエビデンスの世界です。システムに障害は付きものですので、障害報告を行う際には、必ず「1次報告」「中間報告」「最終報告」をエビデンス付きで提出しなければなりません。シェルスクリプトを作成する場合、予め障害が発生することを念頭に入れて設計を進めていきます。基盤として挙げるなら「CPU」や「メモリ」、「ディスク」など、リソース周りの障害は約束されていることです。では、そのエビデンスとして必要になるものは何でしょう？エビデンスとして必ず必要になるものとは、ずば...

[<BASE_DIR>/scripts/bin/func.sh ]

多重起動禁止処理の実行結果

別々のコンソールから「utils.sh」をそれぞれ実行します。

2行目：一発目のスクリプトがPID：17492で実行されました。
3行目：ロック機能により、ロックディレクトリが作成されました。
4行目：一発目のスクリプト（PID：17492）の成功ログが出力されています。
5行目：２発目の同一スクリプトがPID：17502で実行されました。
6行目：既にロックディレクトリが存在するため、新たなディレクトリの作成に失敗。
7行目：2発目の同一スクリプト処理が中断されました。
8行目：一発目のスクリプトの処理が実行されています。
9行目：一発目のスクリプトが正常に終了しました。

実践環境を整える

ここまで学んだ知識を実際に試すには、Linuxを動かす環境が必要です。手軽に始めるならVPSを利用するのがおすすめです。
→ VPS徹底比較！ConoHa・さくら・Xserverの選び方

Beエンジニア

VPS徹底比較！ConoHa・さくら・Xserverの選び方

https://www.pmi-sfbac.org/vps-comparison-conoha-xserver-sakura

国内で人気の高いVPSサービス「ConoHa VPS」「さくらのVPS」「エックスサーバーVPS」。どれも高性能で魅力的な選択肢ですが、用途や重視ポイントによって最適な選び方は変わってきます。この記事では、料金、スペック、操作性、サポート体制などを徹底比較しながら、あなたにぴったりのVPSを見つけるためのヒントをわかりやすく紹介します。それでももし、VPSをどれにするか迷っているなら、まずは ConoHa VPS を選べば間違いありません。料金・使いやすさ・安定性のバランスが良く、初心者から実務利用まで幅広く対応できます。主要3...

VPSを利用してLinux環境を準備したら、実際の設定は下記の記事が参考になります。
→ VPSに開発環境を自動構築する方法｜Apache＋Tomcat＋PostgreSQL

Beエンジニア

VPSにJavaアプリの開発環境を自動で構築する方法：Apache＋Tomcat＋PostgreSQL

https://www.pmi-sfbac.org/rhel-server-setup

開発環境を整えるとき、いきなり細かい設定から入ってしまうと、構築の全体像が見えず混乱しがちです。本シリーズでは、5つのパートに分けて順を追って開発環境を構築していきます。この構成は、構築に必要な順序でステップを並べ（クラウド → Web → AP → DB → 保守）、各パートは独立して読めるようにし、スクリプトによる自動化を前提に操作負担を極力減らす方針に基づいています。ただし、手動で対応すべき設定も明示的に解説します。構築する環境のイメージ最終的に以下のような構成になります。Webサーバ → アプリサーバ → データ...