/usr/local/etc/pkgtools.confのAFTERINSTALLというところに、
AFTERINSTALL = {
'ナントカ' => proc { |origin|
cmd_restart_rc(origin)
},
}
とか書いておくと、portupgradeでナントカをアップデートしたとき、「/usr/local/etc/rc.d/ナントカの起動スクリプト restart」が自動的に実行される、という機能があります。
サーバーとして動作しているソフト（デーモン）のバージョンアップをしたときに、自動的に、デーモンを再起動してくれるので、けっこう便利な機能です。
ちなみに、勝手に再起動してもらっちゃ困るぞ！というタイプのソフトウェアについては、私の場合、HOLD_PKGSのほうに書いておいて、portupgradeで不用意にバージョンアップさせないようにしています。portupgrade -f ～と、「-f」オプションを付ければ、バージョンアップできます。
☆
さて、sysutils/halなんですが、pkgtools.confに
AFTERINSTALL = {
'sysutils/hal' => proc { |origin|
cmd_restart_rc(origin)
},
}
と書いておいても、portupgradeが完了した時点で、hal（コマンド名はhald）は動いてくれません。もともとhaldが動いていた状態でportupgradeすると、haldが停止した状態で終了してしまいます。なんか、昔からそういう挙動をしています。haldが動いていないと、困ったことになる場合があるので、この挙動、かなり嫌なんです。
portupgradeが終わるころのログメッセージはこんな感じです。
cmd_start_rcを書いた場合
===> Installing rc.d startup script(s)
===> Compressing manual pages for hal-0.5.11_23
===> Running ldconfig
/sbin/ldconfig -m /usr/local/lib
===> Registering installation for hal-0.5.11_23
[Updating the pkgdb <format:bdb_btree> in /var/db/pkg ... - 922 packages found (-0 +1) . done]
---> Executing a post-install command for 'sysutils/hal': /usr/local/etc/rc.d/hald start
Starting hald.
---> Cleaning out obsolete shared libraries
cmd_restart_rcを書いた場合
===> Compressing manual pages for hal-0.5.11_23
===> Running ldconfig
/sbin/ldconfig -m /usr/local/lib
===> Registering installation for hal-0.5.11_23
===> Cleaning for hal-0.5.11_23
[Updating the pkgdb <format:bdb_btree> in /var/db/pkg ... - 922 packages found (-0 +1) . done]
---> Executing a post-install command for 'sysutils/hal': /usr/local/etc/rc.d/hald stop; sleep 3; /usr/local/etc/rc.d/hald start
hald not running? (check /var/run/hald/hald.pid).
Starting hald.
---> Cleaning out obsolete shared libraries
これを見る限り、どちらの場合も、/usr/local/etc/rc.d/hald startを実行しているようです。
ちょっとports/sysutils/hal/files/hald.inに小細工をして調べてみたところ、確かに、haldを起動しようとしていることは確認できました。
+ debug checkyesno: hald_enable is set to YES.
+ return 0
+ echo Starting hald.
Starting hald.
+ _return=0
+ [ 0 -ne 0 ]
+ return 0
+ _run_rc_postcmd
+ [ -n ]
+ return 0
+ return 0+
iter=0
---> Cleaning out obsolete shared libraries
「/usr/local/etc/rc.d/hald start」を手で実行すれば、ちゃんと起動するのに、portupgradeから「/usr/local/etc/rc.d/hald start」を実行した場合は、なぜかhaldが起動しない。
なんとも、謎の現象です。
問題の中心は、/usr/local/etc/rc.d/haldの以下の部分らしいです。
hald_start()
{
if ! checkyesno hald_enable ; then
return 0
fi
echo "Starting ${name}."
( iter=0
while ! ps -axoargs | grep "^/usr/libexec/getty " | grep -qv grep >/dev/null 2>&1; do
if [ ${iter} -eq 60 ]; then
break
fi
sleep 1
iter=$(expr ${iter} + 1)
done
${command} ${hald_flags} ) &
}
iter=0は実行されているようですが、そこで終わっていて（？？？）、${command} ${hald_flags}が実行されていないみたいです。
ところで、ここの処理、こんなことをやってるんですね。
- gettyが起動するのを待ってから、haldを起動させたい
- でも永遠に待ち続けるのはナニなので、せいぜい60秒くらいまでにしておく
- ほかのrcスクリプトを実行したいので、/usr/local/etc/rc.d/haldの実行は、60秒も待つことなく、すぐに終わらせたい
( ～ )で囲んであるので、subshellで実行されるんだと思いますが、ためしに、このカッコをとっぱらって、
iter=0
while ! ps -axoargs | grep "^/usr/libexec/getty " | grep -qv grep >/dev/null 2>&1; do
if [ ${iter} -eq 60 ]; then
break
fi
sleep 1
iter=$(expr ${iter} + 1)
done
${command} ${hald_flags}
にしてみたところ、portupgrade完了後、ちゃんとhaldが起動しました！
うーん、なぜだ？！
/bin/shのバグでしょうか？
