web-dev-qa-db-ja.com

一部のLinuxディストリビューションではsystemdサービスがデフォルトで有効になっているのに、他のディストリビューションでは有効になっていないのはなぜですか？

Debianでapt-getを介してパッケージをインストールした後、systemdのサービスがデフォルトで有効になっていることに気づきました。ただし、Arch Linuxなどの他のディストリビューションでは、そのパッケージのサービスはデフォルトで無効になっています。

私の質問は次のとおりです。

  1. この動作は何に依存しますか？それはパッケージマネージャーの設定ですか、それともパッケージ自体が有効にするかどうかを決定しますか？

Debianでは、インストール後にsystemctl enable docker.serviceが実行されたように見えます。また、Arch-linuxではdocker.serviceが無効になっています。

  1. どうすれば変更できますか？
linuxdebianarch-linuxsystemd
2
RndGuyFromInternet

systemdのプリセット宣伝文句が述べているように 、これはディストリビューターによるポリシーの選択です：

Fedoraでは、すべてのサービスがデフォルトでオフのままであるため、パッケージをインストールしてもサービスが有効になることはありません（一部の例外を除く）。 Debianでは、すべてのサービスがデフォルトですぐに有効になるため、パッケージをインストールすると、そのサービスがすぐに有効になります。

理論的には、systemdディストリビューションは、パッケージのインストール後にサービスを有効にするかどうかを決定するためにプリセットシステムを使用し、パッケージのインストール後のメンテナンススクリプトでsystemctl presetではなくsystemctl enableを実行します。ローカルオーバーライドを配布ポリシーに適用するのは、/etc/systemd/system-preset/で独自の優先度の高いプリセットを作成するのと同じくらい簡単です。 （ここでは、Arch docoはかなり誤解を招く可能性があります。通常は、特定のサービスに対応する個別のローカルプリセットファイルを作成します。）

実際には、一部のsystemdディストリビューションは、このためにプリセットシステムを使用しません。また、ローカルオーバーライドをsystemdに適用することは、ディストリビューション自体のメカニズムを使用することです。

参考文献

6
JdeBP

1）この動作は何に依存しますか？それはパッケージマネージャーの設定ですか、それともパッケージ自体が有効にするかどうかを決定しますか？

各ディストリビューションは、DebianのaptやArchLinuxのpacmanなどの異なるパッケージマネージャーを使用する場合があります。これには、ソフトウェア開発者やパッケージメンテナが、さまざまな（多くの場合一貫性のない）方法でパッケージを準備する必要があります。このような違いは、パッケージの設定に関連している可能性がありますが、systemdがターゲットシステムで使用されることを想定せずにパッケージが準備される場合があります。

2）どうすれば変更できますか？

ディストリビューションの特定のパッケージがどのように準備および保守されているか、およびその責任者を確認してください。オープンソースの場合、インストールソースで自分で動作を変更できる可能性があります。また、ソフトウェア開発者/メンテナコミュニティの誰かに連絡して変更を提案することもできます。

3
Michał Kasiński