web-dev-qa-db-ja.com

systemdは/etc/init.dスクリプトをどのように使用しますか？

私はdebian jessieに切り替えたところ、グラフィカルディスプレイマネージャーwdmを含め、ほとんどの問題が解決しました。

問題は、これがどのように機能するのか理解できないことです。明らかに私の/etc/init.d/wdmスクリプトが呼び出されます。これは、初期のexitをそこに置いたときに、wdmが開始されないためです。しかし、代わりに/etc/rc3.dディレクトリの名前を変更すると（私のデフォルトのランレベルは3でした）、wdmはまだ起動しています。

Systemdがこのスクリプトを見つける方法を見つけることができず、他のすべてのinit.dスクリプトに対してそれが何をするのか理解できません。

  • Systemdはいつ、どのようにinit.dスクリプトを実行しますか？
  • 長期的には、すべてのinit.dスクリプトを削除する必要がありますか？
systemdinit-scriptinitsysvinit
131
Martin Drautzburg

カオスの答えは、いくつかのドキュメントが言うことです。しかし、それはsystemdが実際に行うことではありません。 （van Smoorenburg rcもそうではありません。- van Smoorenburg rc 間違いなくしませんでしたLSBヘッダーを無視します。これは、insservが静的順序付けの計算に使用したものです。）まず、「非互換性」ページなどのFreedesktopドキュメントは、これらの点やその他の点で実際には間違っています。 （実際にはHOME環境変数isが設定されることがよくあります。これは、長い間、どこにも完全に文書化されていませんでした。少なくとも、マニュアルでは、FreedesktopのWWWページはまだ修正されていません。

Systemdのネイティブサービス形式はservice unitです。 systemdのサービス管理はsolelyとして機能し、（システム全体の）.serviceファイルが可能な9つのディレクトリの1つから読み取ります住む。 /etc/systemd/system、/run/systemd/system、/usr/local/lib/systemd/system、および/usr/lib/systemd/systemは、これらのディレクトリのうちの4つです。

Van Smoorenburg rcスクリプトとの互換性は、systemd-sysv-generatorという名前の変換プログラムで実現されます。このプログラムは/usr/lib/systemd/system-generators/ディレクトリにリストされているため、bootstrapプロセスの早い段階で、systemdが再ロードするように指示されるたびに、systemdによって自動的に実行されます。後で設定します。

このプログラムはgeneratorであり、サービスユニットファイルをオンザフライで作成するタイプの補助ユーティリティです。ディレクトリ（ジェネレータによってのみ使用されることを目的としています）が配置されています。 systemd-sysv-generatorは、/etc/init.dからvan Smoorenburg rcスクリプトを実行するサービスユニットを生成します（他の6つの場所に既に存在するその名前のネイティブのsystemdサービスユニットが見つからない場合）。

systemdサービス管理はサービスユニットのみを認識します。これらの自動的に（再）生成されたサービスユニットは、van Smoorenburg rcスクリプトを呼び出すように記述されています。彼らは、とりわけ、持っています：

[Unit] 
 SourcePath =/etc/init.d/wibble 
 [Service] 
 ExecStart =/etc/init.d/wibble start 
 ExecStop =/etc/init.d/wibble stop

Van Smoorenburg rcスクリプトにはLSBヘッダーが必要であり、/etc/rc?.d/システムによって課せられた優先順位を尊重せずに並行して実行されるという知識が得られました。これはすべての点で正しくありません。

実際、LSBヘッダーは必要ありません。これらのヘッダーがない場合、systemd-sysv-generatorは、より限定的な古いRedHatコメントヘッダー（description:、pidfile:など）を認識できます。 。さらに、LSBヘッダーがない場合は、/etc/rc?.dシンボリックリンクファームのコンテンツにフォールバックし、リンク名にエンコードされた優先度を読み取り、それらの前/後の順序を構築して、サービスをシリアル化します。 LSBヘッダーが要件ではないだけでなく、LSBヘッダー自体が、物事をある程度シリアル化する前後にエンコードするだけでなく、完全に存在しない場合のフォールバック動作は、実際にはかなり並列化されていない操作です。

/etc/rc3.dが問題にならなかった理由は、おそらく別の/etc/rc?.d/ディレクトリを介してそのスクリプトを有効にしたためです。 systemd-sysv-generatorは、/etc/rc2.d/、/etc/rc3.d/、/etc/rc4.d/のいずれかにリストされていることを、systemdのWanted-Byへのネイティブmulti-user.target関係に変換します。実行レベルはsystemdの世界では「時代遅れ」であり、それらについて忘れることができます。

参考文献

176
JdeBP

SystemdはSysV initスクリプトで 後方互換 です。 LSB 3.1によれば、initスクリプトには情報 コメント規則 が必要であり、スクリプトをいつ開始/停止する必要があるか、およびスクリプトを開始/停止するために何が必要かを定義します。これは例です：

### BEGIN INIT INFO
# Provides: my-service
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Default-Start:  2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start and stop service my-service
# Description: my-service blah blah ...
### END INIT INFO

これはコメント付きのセクションであり、SysVでは無視されます。一方、systemdはその依存関係情報を読み取り、それに応じてそれらのスクリプトを実行します。

しかし、systemdとSysVがinitスクリプトの点で異なる点が1つあります。 SysVは、ファイル名の番号に基づいてスクリプトを順番に実行します。 Systemdはサポートしていません。依存関係が満たされている場合、systemdはスクリプト名の番号付けを尊重せずに、スクリプトをすぐに実行します。それらのいくつかは、おそらく順序付けのために失敗します。他にも考慮すべき多くの 非互換性 があります。

同じサービスにinitスクリプトと.serviceファイルがある場合、systemdは依存関係が満たされるとすぐに両方を実行します（initスクリプトの場合、LSBヘッダーで定義されているもの）。

19
chaos