この質問 に続いて、ヘッドレスUbuntu Server 11.04ボックス用のシンプルなスタートアップサービス(/ etc/init/pms.conf)を次のように書きました。次のとおりです。
start on filesystem and net-device-up IFACE=eth0
stop on runlevel [016]
respawn
exec /home/administrator/pms-current/PMS.sh
コマンドラインからこのサービスを自由に開始(または停止)できます。
service pms start
そして、実際に実行されていることがわかります。
ただし、最初にマシンを起動すると、サービスは開始されません。ボックスにSSH接続して、サービスのステータスを確認すると、次のメッセージが表示されます。
$ service pms status
pms stop/waiting
私の質問は、なぜこれが起こっているのですか?ブート時にサービスが開始されないのはなぜですか?
UPDATE 1:私のサービスが開始され、その後死にかけているのか、まったく開始されていないのかがわからないため、次をPMS.shに追加しました。
echo "STARTED" > $STARTLOG
これは明らかに私に何かを探すことを与えます。自分でサービスを開始し、start.logをチェックして、これをテストしました。次に、start.logを削除して再起動しました。再起動後には存在しなかったので、upstartが間違いなく私のサービスを開始していないようです。私はそれがプロセスの初期の段階で死にかけているかもしれないと思いますが、それがすべての単純さを考えると、それはむしろありそうにないようです。
UPDATE 2:アップグレードを含む11.10にアップグレードしましたが、この問題は引き続き発生します。
UPDATE 3:要求どおり、--debug
で起動しました。 cat /var/log/syslog | grep init
の出力は長すぎて質問に入れることはできませんが、表示するのは here です。
ジョブの冗長性を高めることをお勧めします。開始前/開始後エントリを使用します。
pre-start script
logger "pre-start for myprog"
end script
post-start script
logger "post-start for myprog"
end script
# and for PMS itself:
script
logger "just before executing PMS"
exec /home/administrator/pms-current/PMS.sh
end script
おそらくここで起こっているのは、ネットワークアダプターが起動する前に、おそらくループバックアダプター(lo)よりも前にpmsが起動していることです。 PS3 Media Serverについて話していると仮定すると、それはネットワーク化されたサービスであり、おそらく利用可能なインターフェースがない状態で起動するのは好きではありません。
基準の開始を次のように変更してみてください。
start on filesystem and net-device-up IFACE!=lo
つまり、「実際の」ネットワークインターフェイスが起動した後に開始します。ただし、eth0が次のインターフェイスである場合、PMSは起動しますが、PMSにwlan0を使用させたい場合は、それは理想的ではありません。サービスは開始されますが、リッスンするインターフェイスを選択できなかった可能性があります。ストリーミングするインターフェイスを知っていて、変更されないと仮定して、ジョブにハードコードします。たとえば:
start on filesystem and net-device-up IFACE=wlan0
Oneiric(11.10)では、イベントstatic-network-up
を使用して、静的に構成されたすべてのデバイスを待機できます。これは、インターフェイスをハードコーディングせずにネットワーク依存のジョブを作成できるため便利です。 [注:「すべての静的に構成されたデバイス」とは、NetworkManagerの代わりに/etc/network/interfaces
を使用することを指します。静的IPとDHCPの意味で静的という意味ではありません。]
私は同じ問題を抱えていて、最終的にそれを解決しました単純にで:
start on runlevel [2345]
net-device-up
またはstarted networking
のものなし
これは完全なupstartスクリプトであり、完全に機能します:
# MyApp
description "MyApp"
author "me"
start on runlevel [2345]
stop on runlevel [016]
respawn
exec /usr/bin/myapp 2>> /var/logs/myapp.log
代わりにランレベルで開始を使用して、同様の問題を修正することができました。
start on runlevel [2345]
Syslogを調べることから、pmsプロセスはエラーなしで開始されますが、しばらくするとその目標が開始から停止に変更されて終了します。
Repsawn句を追加しているので、これは少し奇妙です。停止した後、再起動を試行する必要がありますが、実行しません。だから私はあなたがrespawn句を削除したと推測しています。
Pmsサービスの開始と停止の間に、2つのサービスのみがufwとネットワークインターフェイス(eth0)を開始し、1つがudev-fallback-graphicsを開始します。
Pmsを並行して開始しているようです。残念ながら、スタートアップドキュメントは、start on ...
Vanillaとstart on starting ...
およびstart on started ...
の正確な違いについて少しあいまいです。
スタートアップスタンザを次のように変更してみてください
start on started networking
またはちょうどあまりにも
start on net-device-up IFACE=eth0
ログ出力は、net-device-upイベントがかなり遅れて来ますが、pmsはその前に開始するため、少し奇妙です。
これにより、プロセスが一度だけ開始されるようになりますallネットワーキングのセットアップが終了しました。つまり、ジョブは開始されただけでなく終了しました。
また、ログ出力を完全に信頼しないでください。起動プロセスの早い段階で、ファイルへのログ出力が常に機能するとは限りません。 Debugging Upstart の回答を参照してください
これに対する解決策を見つけましたが、理解できません。 rootを所有者として/home/administrator
からPMSを/bin/pms
に移動すると、すべて正常に動作します。
/home/administrator/
の下に置いたまま、ルートが/home/administrator/
ディレクトリ自体のすべての所有者であることを確認すると、まだ機能しません。
管理者をすべての所有者として設定し、スクリプトの関連部分を次のように変更した場合:
Sudo su administrator -c '/home/administrator/pms-current/PMS.sh'
それでも動作しません。
今は/home/root/
ディレクトリを作成し、そこにすべてを移動すると思いますが、これを完全に理解したいと思います。
ホームディレクトリはNFSにありますか?ルートがNFSにアクセスできない場合があります。
記録のために、12.04のちょっとしたテストで:
start on started networking
およびstart on network-interface-up INTERFACE=eth0
は機能しませんが、
start on started network-interface INTERFACE=eth0
はありません。
http://os4.org/wiki/upstart.html に感謝しますinitctl list
alwaysジョブネットワークが停止していることを示します。
RHCSA/CEトレーニング中にchkconfig
に出会いました:
Sudo apt-get install chkconfig
Sudo chkconfig pms on
その機能の詳細については、Oneiric manページ を確認できます。
私のスクリプトが自宅にあるファイルに依存しており、標準のubuntuメカニズム(.Private)で暗号化されているため、ホームにアクセスできないことに気付いたとき、同様の「開始なし」の問題がありました。
start on local-filesystems
イベントは、(おそらく)復号化プロセスが終了する前に発行されます。
@xuhccと同様に、Vagrant Upstartスクリプトが実行されなかった理由を見つけるためにここに来ました。以下が動作するはずです。
浮浪者にマウントして起動
ただし、一部のビルドでは、次のバグが原因で発生しません。
https://github.com/mitchellh/vagrant/issues/6074
レポートに記載されている回避策は、私にとって非常に効果的でした。
$ cat /etc/init/workaround-vagrant-bug-6074.conf
# workaround for https://github.com/mitchellh/vagrant/issues/6074
start on filesystem
task
env MOUNTPOINT=/vagrant
script
until mountpoint -q $MOUNTPOINT; do sleep 1; done
/sbin/initctl emit --no-wait vagrant-mounted MOUNTPOINT=$MOUNTPOINT
end script
私にとって素晴らしい仕事をした
それは私のために働いた(iface up後にサービスを開始する必要があります):
start on started networking and net-device-up IFACE=wlan1
stop on shutdown
respawn
respawn limit 10 10
私の場合、upstartサービスはvagrant synced folderにあるスクリプトに依存していました。次の行を使用して問題を解決しました。
start on vagrant-mounted
詳細: http://razius.com/articles/launching-services-after-vagrant-mount/