システムがSysV、Upstart、またはSystemd initsystemを使用しているかどうかを確認する方法
最近のDebian wheezyまたはFedoraシステムなどで使用されているinitsystemを見つける簡単な方法はありますか？私はFedora 21がsystemd initsystemを使用していることを認識していますが、それは私がそれを読んだことと、関連するすべてのスクリプト/シンボリックリンクが/etc/systemd/に格納されているためです。ただし、Debian squeezeやCentOS 6 or 7などについてはわかりません。
そのようなinitsystemを検証するためにどのようなテクニックが存在しますか？
システムをあちこち調べて、インジケーターを見つけることができます。 1つの方法は、3つのディレクトリの存在を確認することです。
/usr/lib/systemdは、systemdベースのシステムを使用していることを示します。/usr/share/upstartは、Upstartベースのシステムを使用していることを示す非常に優れた指標です。/etc/init.dは、ボックスの履歴にSysV initがあることを示します
問題は、これらはヒューリスティックであり、特定の指標ではなく、他のデータと一緒に考慮する必要があることです。私が今見ているUbuntu 14.10ボックスには、3つのディレクトリがすべて含まれています。どうして？ UbuntuはそのバージョンでUpstartからsystemdに切り替えただけですが、下位互換性のためにUpstartとSysV initを保持しています。
結局、「経験」が一番の答えだと思います。 CentOS 7ボックスにログインし、それがsystemdであることがわかります。これをどのように学びますか？遊んだり、RTFMしたりなど、すべての経験を積むのと同じ方法です。
これはあまり満足のいく答えではないことを理解していますが、それは市場に断片化があり、非標準のデザインが作成されている場合に起こります。 lsが-Cを受け入れるか、--colorを受け入れるか、またはカラー出力をまったく行わないかを確認するようなものです。繰り返しになりますが、答えは「経験」です。
Initプロセスには常にPID 1が割り当てられます。/procファイルシステムは、PIDが指定された実行可能ファイルへのパスを取得する方法を提供します。
言い換えると：
nathan@nathan-desktop:~$ Sudo stat /proc/1/exe
File: '/proc/1/exe' -> '/sbin/upstart'
ご覧のとおり、私のUbuntu 14.10ボックスのinitプロセスはUpstartです。 Ubuntu 15.04はsystemdを使用しているため、代わりにこのコマンドを実行すると、次の結果が得られます。
nathan@nathan-gnome:~$ Sudo stat /proc/1/exe
File: '/proc/1/exe' -> '/lib/systemd/systemd'
現在使用しているシステムで/sbin/initが返された場合は、そのファイルを評価してみてください。
nathan@nathan-gnome:~$ Sudo stat /proc/1/exe
File: '/proc/1/exe' -> '/sbin/init'
nathan@nathan-gnome:~$ stat /sbin/init
File: ‘/sbin/init’ -> ‘/lib/systemd/systemd’
それを実行して詳細を確認することもできます。
[user@centos ~]$ /sbin/init --version
init (upstart 0.6.5)
Copyright (C) 2010 Canonical Ltd.
これは実際にはかなり難しい問題です。主な困難の1つは、これを最も頻繁に実行したい場所が、インストールまたは変更の最中にある可能性が非常に高い場所であるということです。もう1つは、インストールされているシステム管理ツールセット、現在実行中のシステム管理ツールセット、およびシステム間に微妙ではあるが非常に重要な違いがあることです。次回の起動時に実行される管理ツールセット。
もちろん、何がインストールされているかを判断することは、パッケージマネージャーで行います。ただし、複数のシステムを並べてインストールできるため、これはさらに複雑です。
たとえば、Debian Linuxでは systemd パッケージをインストールできますが、それをアクティブなシステムにするのは個別の systemd-sysv パッケージのインストールです。意図は、systemdと sysvinit パッケージを同時にインストールできることです。実際、Debian Linuxの群衆は、Debian 8で、「非アクティブ化」パッケージがしないというまさにその理由により、異なる名前（/lib/sysvinit/init、/lib/systemd/systemd、/sbin/runit-init、/sbin/minit、/sbin/system-managerなど）を持つすべてのプログラムに移行するための措置を講じています。 /sbin/initという名前では競合しません。 /sbin/initは、「アクティブ化パッケージ」によって次回の起動時に実行するように構成された方へのシンボリックリンクです。
現在何が実行中で次に実行する準備ができているかを判断するには、一連のツールセット固有のテストでのみ、偽陽性によるさまざまな程度のリスクとさまざまな程度のドキュメントでのみ行うことができます。具体的には、現在実行されているシステムマネージャーを確認するには、具体的には、プロセスリストまたはシステムマネージャーが公開しているさまざまなAPIを実際に確認する必要があります。しかし、これには完全に落とし穴がないわけではありません。
一般的なスターター以外
間違いなくnot機能するものから始めましょう。
/proc/1/exeは、upstartまたはSystem 5initが現在実行されている場合、同じ/sbin/initを指します。また、一部のシステムでは、systemdの実行中は/sbin/initになります。前述のように、Debian Linux群衆は、異なる名前を持つすべてのプログラムにシフトしたいと考えていました。しかし、これはDebian固有であり、ユニバーサルからfarであり、プログラムが
/sbin/initとして（ブートストラップのinitramfsフェーズによって）呼び出された場合、実際には役に立ちません。 Felix von Leitnerのminitだけが実際にDebian 8によってパッケージ化され、独自の名前で呼び出されます。- 制御APIファイル
/dev/initctlの存在は、System 5initに固有のものではありません。 systemdには、これを処理する（非プロセス＃1）systemd-initctlサーバーがあります。 Joachim Nilssonのfinitも提供しています。 （さらに面白くするために、Debianでは現在/run/initctlにあります。詳細は https://superuser.com/a/888936/38062 を参照してください。） - systemd、upstart、System 5
rc、およびOpenRCはすべて、前の2つの場合の下位互換性のために/etc/init.d/を処理します。その存在は、特定のシステムの存在を示すものではありません。
検出システム5 init
皮肉なことに、 https://unix.stackexchange.com/a/196197/5132 で説明されているように、一方通行少なくともDebian Linuxではシステム5の不在を検出するためにinitは/etc/inittabがないことです。しかしながら：
- これは、
/etc/inittabのようなものをパッケージ化するDebianの方法の副作用です。 - 全体的な問題の一部は、パッケージをアンインストールしても構成ファイルが削除されないため、System 5
initが使用された場合、/etc/inittabが残ります過去の任意の時点。 （Debian 7には、/etc/inittabにエントリを追加してインストールするパッケージがいくつかあるため、これはDebian 8の作業にとってかなり大きな問題でした。） - これは反転テストです。
Systemdの検出
「公式な」方法で実行中のシステムマネージャーとしてsystemdを確認するには、/run/systemd/systemの存在を確認します。これは/run内のディレクトリであり、systemd自体が起動時に作成され、他のシステムマネージャが作成することはほとんどありません。
しかし、それは単にnlikelyです。 selessd もこのディレクトリを作成するため、このチェックはすでに壊れていますです。
その他の非公式なチェックは機能しません。
- systemdはD-Busを介してRPC API全体を公開します。バージョン名と番号も含まれます。だが：
- これは悪名高い "Interface Stability Guarantee" の対象ではなく、明日または気まぐれに変更される可能性があります。
- systemd-shim の類似したD-Busサーバーも同様です。
- 同様に役に立たない。
/run/systemd/privateの存在は同様に保証されず、uselessdによって同様に複製されます。
Noshを検出しています
system-manager in nosh は、/run/system-managerディレクトリを作成します。しかし、これは同等のsystemdチェックの弱点を共有しています。
さらに非スターター：
- Nosh
system-managerの設計では、ファイルシステムにパイプやソケットは作成されず、そもそもRPC APIがありません。 - Nosh
service-managerは通常、/run/service-manager/controlにAPIソケットを持っていますが、他のシステムマネージャの下でnosh service managerを実行できます。したがって、これはsystemマネージャーがプロセス＃1として実行されていることを通知しません。いずれにしても、その名前自体は設定されません。それを呼び出したものは何でもします。 system-control version、systemctl version（systemd互換性シムがインストールされている場合）およびinitctl version（起動時互換性シムがインストールされている場合）によって発行されるnoshバージョン文字列の存在は、これらのツールがクエリを実行しないため、ツールセットの存在を示すだけです。実行中のシステム。
新興企業の検出
Upstart独自のinitctlは、D-Bus経由でAPI呼び出しを行います。公式チェックは、どちらかがinitctlを実行できることと、その出力に「upstart」という文字列が含まれていることを確認することです。
しかし、systemd APIのように：
- APIが明日前後になるか、気まぐれに変更されないという保証はありません。
- 一部の互換性シムが存在しない、または将来存在しないという保証はありません。
実際、互換性シムはすでに1つあります。 noshには、upstart
initctl、start、stop、およびstatusコマンド用のシムを提供するupstart互換パッケージがあります。幸いなことに（これは意図的なものですが）、initctlshimはWordの「upstart」を出力しません。root〜#initctl version nosh version 1.14 root〜＃
RPMベースのシステムでは、RPMデータベースにクエリを実行して、/sbin/initが提供するパッケージを確認できます。例えば：
Fedora:~$ rpm -qf /sbin/init
systemd-216-24.fc21.x86_64
centos:~$ rpm -qf /sbin/init
upstart-0.6.5-12.el6_4.1.x86_64
opensuse:~$ rpm -qf /sbin/init
systemd-sysvinit-44-10.1.1.i586
バージョンではなくパッケージ名だけが必要な場合は、--qfオプションをRPMに追加できます（ "queryformat"、other-qfと混同しないでください）。 「クエリ：ファイル」を意味するハイフン、たとえばrpm --qf '%{name}\n' -qf /sbin/init。
Debianベースのシステムでは、dpkgを使用して同様のことができます。
ubuntu:~$ dpkg -S /sbin/init
upstart: /sbin/init
また、ほとんどのパッケージマネージャーにも同様のコマンドがあります。もちろん、ディストリビューションが使用するパッケージマネージャーを知る必要があります。これは、ある問題を別の問題と交換しているだけかもしれません。
また、一部のディストリビューションでは、/sbin/initがカーネルコマンドラインで指定されているため、init=/something/elseが適切なファイルではない可能性があります。別の可能性は、/sbin/initがinitシステム間の切り替えを担当するヘルパーパッケージによって所有され、それらのいずれによっても直接所有されていないシンボリックリンクである可能性があります。これらのいずれかまたは両方がArchのケースである可能性があります（ただし、現時点で確認できるArchボックスはありません）。
プログラムから、そのために定義されたAPIを使用することもできます。 Systemdにはlibsystemdが付属しており、実行中のsystemdインスタンスに正常に接続できるかどうかを確認できます。