デーモンが走らない
次のことを確認しよう。
svstat で見ると、 なんかデーモンの pid がぐるぐる変わっている
それは、run スクリプトがすぐに終了してしまうからである。 supervise は run スクリプトを実行したプロセスが デーモンに override されると思っているから、デーモンが何度も終了したと 思って何度も何度も run を実行しているのだ。それで pid が ぐるぐる変わっているのである。 新しいサービスを走らせる手順 の項を 参照してもう一度 run スクリプトをよく見てみよう。実行しているデーモンが すぐにバックグラウンドに移行してしまうような場合は、 fghack を使う必要があるかもしれない。当然、& なんか 使っちゃダメ。
svc でデーモンが制御できない
おそらく、run スクリプト中で exec を使っていないためだろう。 デーモンは、このスクリプトの pid を override しなければ だめなのだ。 こうしないと supervise にはデーモンの pid が把握できないのである。
#!/bin/sh exec /usr/local/bin/someservice (○)
#!/bin/sh /usr/local/bin/someservice (×)
また、
svc: warning: unable to control qmail: supervise not runningという表示がでる場合は、まだ svscan が supervise を 走らせていない (あるいは svscan 自身が走っていない) ことが 考えられる。すこし待ってからもう一度 svc を実行してみよう。
ログが残らない、ログ用の supervise が走らない
まず、ちゃんとサービス用ディレクトリの sticky bit が立っているか どうか確認しよう。もし不幸にも sticky bit を立てずにディレクトリを 作って、しかもそこに supervise/ ディレクトリができてしまった場合、 そのディレクトリをもう一度作り直すしか方法はない。 cp -r someservice .someservice などを実行して、 i-node が新しいディレクトリをつくり、sticky bit をたてよう。 その後 mv すればうまくいく。 新しいサービスをログ記録つきで走らせる手順 も 参照のこと。
あるいは、ログ用のデーモンはログを残すディレクトリに ちゃんとアクセスできるようになっているかな? uid を変更して multilog を使う場合には必ず log ディレクトリの 所有者、パーミッションを確認しよう。
supervise がエラーを出しつづける
svscan を実行した途端、
supervise: fatal: unable to acquire qmail/supervise/lock: temporary failureという表示がでた場合、それは supervise がそのディレクトリで すでに走っていることを示している (そしてこのような場合は だいたい svscan もすでに走っていることが多い)。 同一のディレクトリで 2つの supervise が走らないように、supervise は 自分の supervise/ ディレクトリに lock ファイルを作る。
一般に、svscan はシステム起動時に rc 内で開始しておけばいいので あって、管理者が svscan を明示的に実行することはほとんどない。
注意: うっかり svscan をどこか ほかのディレクトリで実行しないよう注意しよう。カレントディレクトリの 直下のディレクトリ内がみんなスキャンされてしまって、みんな 中に supervise ディレクトリが作られちゃうよ。
supervise がいつまでたっても終了しない
svscan が走っている限り、supervise は何度でも走る。 サービスを廃止する の項を見て、ただしく supervise を終了させよう。
svscan が起動時に立ち上がらない!
一部の UNIX では、起動時に svscan が立ち上がらない、という現象が 発生する (Digital UNIX, HP-UX などがそうらしい)。 /sbin/init.d/ 以下の起動スクリプトファイルに svscan を立ち上げるような スクリプトを書いても、いざシステムが起動してから ps してみると 死んでいる。
このときの起動スクリプト(すぐ落ちる):
#!/bin/sh echo "Starting svscan..." env - PATH=/usr/local/bin:/usr/bin:bin svscan /service &
この現象は、システムが getty を立ち上げるときに、すべての プロセスに一度 SIGHUP を送ることが原因らしい。そのため SIGHUP に対して何も防御していないプロセス (svscan など) は、 ここですべて終了してしまう。これを防ぐためには SIGHUP で svscan が死なないようにしてやればよい。
落ちない起動スクリプト:
#!/bin/sh echo "Starting svscan..." trap "" 1 env - PATH=/usr/local/bin:/usr/bin:/bin svscan /service &
なお、D.J.Bernstein 氏が svscan のマニュアル に書いている起動方法:
csh -cf 'svscan /service &'は、Digital UNIX ではうまくいかなかった。BSD と SYSV 系では csh の挙動が違うらしい。
svscan がエラーを出しつづける
svscan を起動するときにパスの設定をまちがえると、次のようなエラーが 出つづける:
svscan: warning: unable to start supervise qmail: file does not exist
/usr/local/bin が環境変数 PATH に入っていない状態で svscan を起動してしまうと、supervise はふつう /usr/local/bin に インストールされるので、svscan から見えないことになってしまう。 このエラーはこのようなときに出力される。
svscan を起動するときには、
csh -cf 'nohup env - PATH=/usr/local/bin:/usr/bin:/bin svscan /service &'などとして PATH を明示的に指定しておくほうがよい。 こうしておけば、それ以外の環境変数を消すこともできるので安全だ。
svscan が突然死んでしまった!
svscan がいつのまにか死んでいた、という症例が 1回報告されています。これに対処するスマートな方法は、 いまのところわかりません。ごめんなさい。