デフォルトでは、OSの起動時にsystemdはサービスを開始しますか？

すべてのサービスはデフォルトで「無効」になっており、「有効」はオプションです。

そうなんですか？

systemctl daemon-reloadはい.systemctl start ...​systemctl enable ...​します。systemctl enable --now ....) 同時にアクティブにして起動します。

ただし、systemdデバイスを含むパッケージをインストールすると、パッケージは通常、インストール後のスクリプトの一部としてほとんどのコマンドを実行します。

走り終わった後

sudo apt install openssh-server

sshdが自動的に実行されるのはなぜですか？

したがって、パッケージのインストール後スクリプトはそれを有効にし、インストール後にパッケージを実行します。

あなたはLubuntuにいると言いました。 Debian自体、Ubuntu、Lubuntu、その他のバリアントなどのDebianベースのディストリビューション（通常またはapt-get使用apt）は通常、パッケージがインストールされるとすぐにパッケージを起動してアクティブにします。彼らの哲学は、サービスを開始してすぐに使用できるように、正常で「安全な」デフォルトを提供することです。 （「セキュリティ」とは、localhost以外の接続を許可しないこと、またはキーベースの認証などの強力な認証形式にのみ認証を制限することを意味します。）

Red Hatベースのシステム（RHEL、CentOS、Fedora、およびSuSEも同様）は通常反対のタスクを実行し、管理者がパッケージをインストールした後にデーモンを明示的に有効にして起動する前に、デーモン構成を確認できます。初めて。

systemd は、これに関連してディストリビューションポリシーを考慮するアクティベーションと初期化に関するメカニズムを作成しました。基本。

このメカニズムを使用すると、パッケージャはインストール後にスクリプトから簡単に呼び出すことができるため、展開固有のsystemctl preset ...ポリシーについて心配する必要はありません。

Debianベースのディストリビューションはデフォルトですべてを有効にするポリシーを実装するこの行を含む*.presetファイルをプッシュしますが、Red Hatベースのディストリビューションはデフォルト設定を実装するファイルを提供します。enable **.presetdisable *

これらのデプロイメント固有の設定の背後にあるメカニズムをデプロイメント全体で一貫していることに加えて、systemdプリセットは管理者に特定のプリセットパッケージの別のオプションを選択するか、デプロイメントの元の選択を完全にオーバーライドしてこれらの設定をカスタマイズできます。と一貫した方法を提供します。

実際、Debian ベースのディストリビューションは最終的にsystemctl preset まっすぐ、代わりに周りに小さなラッパーを提供し、これはパッケージのインストール後のスクリプトで使用されます。ラッパーを使用する理由は、パッケージが削除されたときにパッケージのアクティブ化モードを記録し、後で同じホストにパッケージを再インストールする場合に備えて保存するためです。 systemdのデフォルト設定はこれらのホストで通常どおり機能するため、この小さな詳細はほとんど無視できます。