Jak zjistit, zda systém používá SysV, Upstart nebo Systemd initsystem

Proces init je vždy přiřazen PID 1. /proc filesystem poskytuje způsob, jak získat cestu ke spustitelnému souboru s PID.

Jinými slovy:

[email protected]:~$ sudo stat /proc/1/exe
  File: '/proc/1/exe' -> '/sbin/upstart'

Jak vidíte, proces init na mém boxu Ubuntu 14.10 je Upstart. Ubuntu 15.04 používá systemd, takže spuštění tohoto příkazu místo toho vede:

[email protected]:~$ sudo stat /proc/1/exe
  File: '/proc/1/exe' -> '/lib/systemd/systemd'

Pokud systém, na kterém používáte, dává /sbin/init v důsledku toho budete chtít zkusit uvést tento soubor:

[email protected]:~$ sudo stat /proc/1/exe
  File: '/proc/1/exe' -> '/sbin/init'
[email protected]:~$ stat /sbin/init
  File: ‘/sbin/init’ -> ‘/lib/systemd/systemd’

Můžete jej také spustit a zjistit více:

[[email protected] ~]$ /sbin/init --version
init (upstart 0.6.5)
Copyright (C) 2010 Canonical Ltd.

Můžete se pohrabat v systému a najít indikátory. Jedním ze způsobů je zkontrolovat existenci tří adresářů:

• /usr/lib/systemd říká, že používáte systém založený na systemd.

• /usr/share/upstart je docela dobrý indikátor toho, že používáte systém založený na Upstart.

• /etc/init.d říká, že box má ve své historii init SysV

Jde o to, že se jedná o heuristiky, které je třeba posuzovat společně, případně s dalšími údaji, nikoli samy o sobě s určitými ukazateli. Krabice Ubuntu 14.10, na kterou se právě dívám, má všechny tři adresáře. Proč? Protože Ubuntu právě přešlo na systemd z Upstart v této verzi, ale ponechává Upstart a SysV init pro zpětnou kompatibilitu.

Nakonec si myslím, že nejlepší odpovědí je „zkušenost“. Uvidíte, že jste se přihlásili do boxu CentOS 7 a víte, že je systemd. Jak se to naučíš? Hraní, RTFMing atd. Stejným způsobem získáváte všechny zkušenosti.

Uvědomuji si, že to není příliš uspokojivá odpověď, ale to je to, co se stane, když dojde k roztříštěnosti trhu a vzniku nestandardních návrhů. Je to jako zeptat se, jak víte, zda ls přijímá -C nebo --color nebo neprovádí barevný výstup vůbec. Odpověď je opět "zkušenost."

To je vlastně docela obtížný problém. Jedním z hlavních problémů je to, že místa, kde to člověk chce nejčastěji dělat, jsou místa, kde je docela pravděpodobné, že bude uprostřed instalace nebo výměny věcí. Dalším je, že existuje jemný, ale velmi důležitý rozdíl mezi nainstalovanou sadou nástrojů pro správu systému , sada nástrojů pro správu systému, která právě běží a sada nástrojů pro správu systému, která se spustí při příštím spuštění .

Určení toho, co je nainstalováno, dělá samozřejmě správce balíčků. To je však komplikováno skutečností, že několik systémů může být instalováno vedle sebe.

Například na Debian Linuxu lze nainstalovat balíček systemd, ale aktivním systémem je instalace samostatného balíčku systemd-sysv. Záměrem je, aby balíčky systemd a sysvinit mohly být instalovány současně. Zástupci Debian Linuxu skutečně podnikli kroky v Debianu 8 k posunu směrem k tomu, aby každý program měl jiné jméno (/lib/sysvinit/init , /lib/systemd/systemd , /sbin/runit-init , /sbin/minit , /sbin/system-manager , a tak dále) právě z tohoto důvodu, aby "neaktivační" balíčky nebyly v konfliktu se jménem /sbin/init . /sbin/init je pak symbolický odkaz na to, co bylo nakonfigurováno tak, aby se spouštělo při příštím spuštění pomocí "aktivačního balíčku".

Určit, co běží nyní a co je připraveno ke spuštění, lze provést pouze sérií testů specifických pro sadu nástrojů, s různým stupněm rizika falešných poplachů a s různým stupněm dokumentace. Chcete-li zjistit, jaký systémový manažer právě běží, konkrétně se musíte skutečně podívat na seznam procesů nebo na různá rozhraní API, která správci systému publikují. Ale to není úplně bez úskalí.

Obecní nezačátečníci

Začněme věcmi, které rozhodně ne práce.

• /proc/1/exe bude ukazovat na stejný /sbin/init při prvním spuštění nebo systému 5 init běží právě teď. A na některých systémech je to také /sbin/init když běží systemd.

  Dav Debian Linuxu se chtěl posunout k tomu, že každý program bude mít jiný název, jak již bylo zmíněno dříve. Ale toto je specifické pro Debian, daleko z universal a ve skutečnosti nepomůže, když je program vyvolán jako /sbin/init (podle fáze initramfs bootstrapu) každopádně. Pouze minit Felixe von Leitnera je ve skutečnosti zabalen v Debianu 8, aby mohl být vyvolán svým vlastním jménem.

• Existence řídicího souboru API /dev/initctl není specifické pro System 5 init . systemd má (ne proces #1) systemd-initctl server, který to obsluhuje. finit Joachima Nilssona slouží také. (Aby to bylo ještě zábavnější, v Debianu je nyní umístěn na /run/initctl . Podrobnosti viz https://superuser.com/a/888936/38062.)
• systemd, upstart, System 5 rc a OpenRC všechny zpracovávají /etc/init.d/ , pro zpětnou kompatibilitu v případě předchozích dvou. Jeho existence nenaznačuje přítomnost žádného daného systému.

Detekce systému 5 init

Ironicky, jak je vysvětleno na https://unix.stackexchange.com/a/196197/5132 , jeden způsob alespoň na Debian Linuxu pro detekci nepřítomnosti System 5 init je nepřítomnost /etc/inittab . Nicméně:

• Toto je vedlejší účinek způsobu, jakým Debian balí věci jako /etc/inittab .
• Jednou součástí celkového problému je /etc/inittab zůstane, pokud System 5 init byl použit kdykoli v minulosti , protože odinstalování balíčku neodstraní jeho konfigurační soubor. (Pro práci s Debianem 8 to byl značný problém, protože v Debianu 7 je několik balíčků, které se samy instalují přidáním položek do /etc/inittab .)
• Je to obrácený test.

Detekce systemd

Chcete-li zkontrolovat systemd jako běžícího správce systému "oficiálním" způsobem, zkontrolujte existenci /run/systemd/system . Toto je adresář v /run , který systemd sám vytváří při bootování a který ostatní správci systému pravděpodobně nevytvoří.

Ale to je pouze nepravděpodobné . Tato kontrola je již porušena , protože uselessd vytváří i tento adresář.

Jiné, neoficiální kontroly nebudou fungovat:

• systemd publikuje celé RPC API přes D-Bus, které dokonce obsahuje název a číslo verze; ale:
  • Na to se nevztahuje nechvalně známá „Záruka stability rozhraní“ a může se změnit zítra nebo podle rozmaru.
  • Stejně jako podobný server D-Bus v systemd-shim.
  • Stejně tak je zbytečné.
• Existence /run/systemd/private není obdobně zaručena a podobně duplikována pomocí uselessd.

Detekce nosu

system-manager v nosh vytvoří /run/system-manager adresář. To však sdílí slabiny ekvivalentní systémové kontroly.

Další nezačátečníci:

• Nosh system-manager podle návrhu nevytváří roury ani sokety v souborovém systému a v první řadě nemá RPC API.
• Nosh service-manager obvykle má zásuvku API na /run/service-manager/control , ale lze spustit službu nosh správce pod nějakým jiným správcem systému; takže to člověku neřekne, jaký systém manažer běží jako proces #1. V každém případě toto jméno nestanoví samo; cokoli vyvolá.
• Existence řetězce verze nosh emitovaného system-control version , systemctl version (pokud máte nainstalovány podložky pro kompatibilitu systemd) a initctl version (pokud máte nainstalované podložky pro kompatibilitu pro začátečníky) pouze indikuje přítomnost sady nástrojů, protože tyto nástroje neprovádějí žádné dotazy na běžící systém.

Detekce začátečníků

Vlastní initctl společnosti Upstart provede volání API přes D-Bus a oficiální kontrolou je ověřit, zda lze spustit initctl a že jeho výstup někde obsahuje řetězec "upstart".

Ale jako systémové API:

• Není žádná záruka, že rozhraní API bude zítra k dispozici nebo že se nezmění z rozmaru.
• Neexistuje žádná záruka, že některá podložka kompatibility neexistuje nebo nebude existovat v budoucnu.

  Ve skutečnosti již existuje jedna podložka pro kompatibilitu. nosh má balíček kompatibility pro začátečníky, který poskytuje shims pro začátečníky initctl , start , stop a status příkazy. Naštěstí (ačkoli to bylo záměrné), initctl podložka nevydává slovo "upstart".

  root ~ #initctl version
  nosh version 1.14
  root ~ #