/sbin/init.d/httpd gracefulを行った際に出てくる"long lost child came home!" とは？

Question

gracefulコマンドを使い、apacheのエラーログを確認してみたらlong lost child came home!と書かれていました。apacheのドキュメントを読んだり検索してみた所（数が本当に少なかったですが）、これはスコアボードが壊れた事により出力されているエラーだという事は理解できています。

今回このgracefulを実行した事によりスコアボードが壊れて、そのスコアボードが新しく生成された後に子プロセスもまた新しくできた事によりlong lost child came home！というメッセージが出力されていた・・・という解釈でいいのでしょうか？

ただ単に終了したプロセスが管理されているスコアボードが壊れたから出力されていると考えると、なんかもっと違うエラー文章の方が良かったのでは？と思ってしまいます。

誰か、深い知識もっている方がいましたら教えていただけますでしょうか？
きっとlong lost child came home!という文章がしっくりくる、という理由があるはず・・・！

Answer 1

原因はわかりませんが、子プロセスからシグナルを受け、その子プロセスの PID がスコアボードに無かったときに該当メッセージが出力されるようです。このメッセージは graceful のときだけで、特にそれ以外の処理は行なっていません。

推測になりますが、
0. graceful で子プロセスに「処理が終わったら死んでね」と通達
0. 子プロセスから「死んだ」という連絡を受けたらスコアボード書き換え
0. 子プロセスから連絡がないまま、新たな HTTPリクエストを捌かないといけないので、連絡のない子プロセスは死んだことにしてスコアボードから削除し、新たな子プロセスを起動＆登録
0. 忘れたころに子プロセスから「死んだ」という連絡を受けたが、スコアボードに無いので、「死んだはずの子が実は生きていた」

とか。
すみません、ちゃんと調べていません。

Answer 2

知り合いの方からSNSを通してコメントを頂いたので、まとめをこちらにも書いておきます。

APACHEの公式サイトでは

「Apache 1.2b9 以前は、再起動や停止のシグナルを含む競合状態 (競合状態を簡単に説明すると: タイミンにグよる問題で、 具合の悪い時間帯にちょうど何かが起こると予想外の動作をする ようなことを指します) がありました。 「正しい」機能を持っているアーキテクチャでは、できるだけ このようなことが起こらないようにしています。 しかし、ある種のアーキテクチャでは競合状態は未だ確実に起こりえる ということに注意してください。
ディ スク上で ScoreBoardFile を使用しているアーキテクチャでは、 潜在的にスコアボードが壊れる可能性があります。 スコアボードが壊れた場合は、 "bind: Address already in use" (HUP 後) や "long lost child came home!" (USR1 後) といった結果になります。」

と書いてあります。
潜在的にスコアボードが壊れるケースもあるので、/sbin/init.d/httpd gracefulを行った時以外にもスコアボードが壊れた可能性があります。そしてその前回スコアボードが壊れた際に、個々の子プロセスで 継続的な HTTP コネクション (KeepAlive) に関する小さな競合状態が起こっていたとすれば、 リクエスト行を読んだ後、そしてリクエストヘッダを読む前に 子プロセスは終了しているはずです。そしてgracefulを行った際に新しくスコアボード共に過去のプロセスで途中で終了させられてしまった子プロセスが再開された為、"long lost child came home!"というエラーメッセージが出るのではないか

という結果に至りました。