rcとupstar

googleがrcとupstartの関係を説明するドキュメントを見付けてこないので印象からrcとupstartの関係をメモる。間違いがあったら指摘してください。

rcはsystemV系のサービス管理。サービス毎に面倒なシェルスクリプと書き、daemonプロセスはその中からpidファイルで管理する。
スクリプトの場所は/etc/init.d/

upstartはinitプロセスによるtty管理を拡張したようなサービス管理システム。daemonプロセスを立ち上げ、終了するという意味ではRCと機能がかぶっている。Ubuntu(debian?)ではRCからupstartに移行中のようだ。Hardyの時代からupstart-compat-sysvというパッケージがあってupstartでsysv rcをドライブしている。(移行と言うよりも、rcはレガシーとしてサポートされ続けるのかもしれない)
スクリプトは/etc/init/にある。古いの(Hardy)では/etc/event.d/。

upstartの利点

initプロセスによる厳密な管理

PIDファイルベースの管理みたいにファイルが掃除されていないために死んだプロセスが生きていることになっているようなことがない。

死んでも生き返る

initプロセスがモニタリングしているので、死んでも即時再起動される。何度か立て続けに死んだら諦めるロジックもあるので、無限ループになるようなことはない。

簡潔なサービス管理スクリプト

RCの/etc/init.d/のスクリプトと/etc/init/(upstart)下のを比べてみるとupstartの方が短かい。コツをつかめばupstartの方が楽。

簡潔な管理コマンド


/etc/init.d/hoge start
の代りに

start hoge
stop statusも同様

upstartの注意点

upstartはPIDファイルでプロセスの生存を把握しない。initが生み出し、親子プロセスの関係(多分ptrace)で管理する。つまり、initがサービスを立ち上げ、forkを追ってdaemonプロセスを管理する。

システム管理者はexpect文によりサーバプログラムのforkパターンをupstartに告げなければならない。expectとexecするプログラムの挙動がマッチしないとスタートしたプロセスが即停止したと認識されたり、startがブロックしたりと、面倒なことになる。

  • expect stop: サーバが準備完了になったらSIGSTOPを送る
  • expect daemon: 二度forkする伝統的なUnixdaemon
  • expect fork: 一度だけforkするプログラム

検証していないが、次のようなパターンが考えられる:

通常のdaemon


expect daemon
exec hoge # daemonizeする

foregroundのままのプログラム


exec hoge -D # daemonizeさせない

明示的にbackgroundにされるプログラム


expect fork
exec hoge -D &

まとめ

expect、execと各プログラムの挙動の関係さえ押えておけば、upstartはパワフルで使い易く、sysv rcより優れたものだ。