(私家版 daemontools FAQ) 3. トラブルシューティング

back


デーモンが走らない

次のことを確認しよう。

  1. svscan は走っているか?
  2. サービス用のディレクトリ (あるいは、そのディレクトリへの リンク) はちゃんと svscan から見える位置に存在しているか?
  3. run スクリプトは実行可能になっているか、また その中ではちゃんとデーモンを exec で起動し、 それはフォアグラウンドで走るか?
  4. サービス用のディレクトリに down という ファイルが存在していないか?
  5. supervise がちゃんと「up」の状態になっているか? svstat /service/サービス名 を実行してみよう。 down になっていたら、 svc -u /service/サービス名 を実行すれば デーモンが走りだす。

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回報告されています。これに対処するスマートな方法は、 いまのところわかりません。ごめんなさい。


Last modified: Wed Sep 26 18:25:41 2001
Yusuke Shinyama