Systemd – principy

4. 5. 2011 | Michal Vyskočil | Systém | 168559×

V dnešním díle bude představen přímo systemd. To jakým způsobem se nastavuje, instaluje, kde zadat parametry a jak se ovládá. Systemd je nejnovější hvězda v tak poklidné a konzervativní oblasti, jako jsou init systémy. V následující sérii článků si probereme jeho vlastnosti.

Obsah

• Co je systemd
• Jednotky (units)
• Důležité adresáře
• Instalace
• Systém nestartuje
• Ovládání jednotek
• Úrovně běhu
• Závěrem

Co je systemd

Shrňme si poznatky z minulých kapitol. Systemd je

• Alternativní init systém
• Částečně zpětně kompatibilní se sysvinit – podporuje init skripty, LSB hlavičky a /dev/initctl
• Podporuje start služeb na vyžádání prostřednictvím socket, D-BUS, časové aktivace nebo aktivace založené na cestě
• Podporuje supervizi procesů pomocí cgroups a kontrolu prostředí spouštěných služeb
• Konfiguruje se pomocí jednotek, textových souborů různých typů

Lennart s prvním blogem nezveřejnil jenom koncept, který by měl někdo implementovat, ale první pracovní verzi svého kódu. Následující text se tedy podívá na systemd z praktické stránky.

Jednotky (units)

Základním stavebním kamenem systemd jsou jednotky (units). Každá jednotka má svůj název a typ a je obvykle uložena v souboru s názvem název.typ - avahi.service je konfigurace jednotky avahi typu služba (.service). Konfigurační formát je jednoduchý, podobný .desktop souborům či .ini souborům z Microsoft Windows. Mimochodem v blogu se Lennart strefuje do System Management Facility, jinak mocného init systému pro Solaris, právě pro použití XML jako konfiguračního formátu. Štěstím je, že po děsivých zkušenostech s HAL a fontcofig není tento formát pro ukládání konfigurace příliš oblíbený. Rozhodně v linuxové komunitě.

Typ jednotky potom značí, co vlastně daná jednotka ovládá. Podporovány jsou

služba (.service) – tento typ ovládá démony – jejich spuštění, zastavení, restart a jiné. Pro zpětnou kompatibilitu se SysV systemd podporuje nejen vlastní formát, ale i /etc/init.d skripty a to včetně parsování LSB hlaviček.

socket (.socket) – tento typ manipuluje se sockety AF_INET, AF_INET6, nebo AF_UNIX sockety. Rovněž je podporována pojmenovaná roura. Každá jednotka má komplementární službu, která je spuštěna v okamžiku, kdy přijde první připojení na socket. Takže nscd.socket startuje službu nscd.service.

zařízení (.device) – konfigurační soubor pro zařízení, tak jak je dostupné v /dev nebo /sysfs. Název souboru musí odpovídat danému zařízení, takže dev-sda5.device obsahuje informace o /dev/sda5. Primárním zdrojem informací a konfigurace je udev, vlastní systemd soubory jsou spíše výjimkou.

připojení (.mount) – tato jednotka reprezentuje přípojné body v souborovém systému. systemd sleduje aktivitu přípojných bodů. Hlavním zdrojem konfigurace je /etc/fstab

automatické připojení (.automount) – reprezentuje přípojné body připojované až v okamžiku prvního pokusu o přístup.

cíl (.target) – logická skupina jednotek – umožňují snížit granularitu nastavení. Například se můžeme odkázat na multi-user.target, což je ekvivalent runlevelu 5 ze sysvinit nebo třeba bluetooth.target, který bude vyžadován po zapojení bluetooth jednotky do systému a který spustí všechny služby jako bluetoothd nebo obexd.

snímek (.snapshot) odkazuje na ostatní jednotky. Smyslem této jednotky je mít možnost uložit aktuální stav všech ostatních jednotek. Například pokud potřebujeme vyvolat nouzovou opravu, uložíme aktuálně běžící jednotky, vyvoláme opravný nástroj a jednotky zase nahrajeme zpět. Spousta služeb totiž nepodporuje uspávání. Systemd je v takovém případě raději vypne a po spuštění obnoví.

odkládací paměť (.swap) je typ jednotek, které obsahují informace o dostupných úložištích pro odkládací paměť. Stejně jako u typu připojení je zdroj informací /etc/fstab.

časovač (.timer) je pro typ jednotek spouštěných na základě časových událostí pro periodicky se opakující se úlohy. Narozdíl od jednotek pro připojení a odkládací paměť se tento typ nesnaží o zpětnou kompatibilitu se systémem cron nebo at, i když je možné, že v budoucnu někdo takovou podporu napíše.

Důležité adresáře

Pro práci se systemd je nezbytné znát, kam vlastně ukládá svoje jednotky. Jsou to adresáře /lib/systemd/system a /etc/systemd/system, respektive adresáře vrácené příkazy

pkg-config systemd --variable=systemdsystemunitdir
pkg-config systemd --variable=systemdsystemconfdir

přičemž vyšší prioritu má adresář /etc/systemd.

Význam je jednoduchý – v /lib jsou ukládány konfigurační soubory distribuované přímo se systemd, případně jiným balíčkem, takže je nelze editovat (tedy lze je editovat, ale pak nesmíme updatovat). Pokud uživatel potřebuje změnit výchozí chování, zkopíruje jednotku do /etc, takže bude použita tato.

Pro zajímavost adresáře pro uživatelské relace jsou $ pkg-config systemd --variable=systemduserunitdir /usr/share/systemd/user $ pkg-config systemd --variable=systemduserconfdir /etc/systemd/user

Dalším adresářem je /etc/init.d/, kde jsou uloženy init skripty, které systemd spouští, pokud neexistuje odpovídající nativní jednotka. Stejně tak používá symbolické odkazy v /etc/rcXYZ (konkrétní umístění se mezi distribucemi mírně liší).

Instalace

Pro hrátky se systemd je dobré jej mít nainstalován. Systemd již vyšel jako technology preview ve Fedora 14 a openSUSE 11.4, což je logické, protože Lennart (Fedora) i Kay Sievers na systemd od počátku spolupracovali. Očekává se, že Fedora 15 a openSUSE 12.1 budou obsahovat systemd jako výchozí možnost. Debian unstable bude rovněž rozumnou volbou. Distribuce jako Arch nebo Gentoo mají systemd v nějakém tom komunitním repositáři, čili nezdá se, že by se snažily konvertovat skripty na systemd, nicméně fungovat by mohl i tam. Vhodnou volbou naopak není Ubuntu, protože instalací systemd přijdete o možnost spouštět programy již konvertované na upstart.

Rozumnou možností, jak zjistit podporu systemd je podívat se do configure.ac na řádek AC_ARG_WITH(distro, kde najdete již podporované distribuční cíle. Ale jako v případě Slackware podpora v systemd neznamená, že najdete hotové balíčky nebo že se jej někdo snaží aktivně protlačovat.

Po absolvování instalační procedury, která bývá popsána na stránkách příslušné distribuce se nabootuje obvykle po zadání init=/bin/systemd a kochat se novým init systémem. Většina uživatelů je překvapena skutečností, že jejich systém nastartoval jako kdykoli předtím.

Systém nestartuje

Ovšem čas od času se stane, že se něco nepovede. Proto systemd nabízí řadu parametrů, kterými lze říci, že potřebujeme více informací. Ony parametry existují ve třech formách – parametr jaderného příkazového řádku, proměnná nebo klasický --argument příkazu. Budu uvádět pouze jadernou variantu, zbytek je v systemd(1).

systemd.crash_shell – může nabývat hodnot true, nebo false a používá se pro případy, že démon spadne. Z bezpečnostních důvodů je zakázána, ale pokud testujete vývojové verze, můžete se s pádem setkat.

systemd.crash_chvt – pozitivní hodnota určuje číslo virtuálního terminálu, na který se systemd v případě pádu přepne

systemd.confirm_spawn – opět může nabývat hodnot true, nebo false a určuje, zda má systemd požadovat interaktivní potvrzení při spuštění každé služby

systemd.log_level – označuje jak podrobný bude výstup systemd – mezi podporované volby patří emerg, alert, crit, err, warning, notice, info, debug, případně ekvivalentní číselné označení. Vhodné, pokud démon dělá něco, co by dle vás vůbec neměl.

systemd.log_target – určuje, kam bude systemd zapisovat svoje zprávy - možnosti jsou console, syslog, kmsg a syslog-or-kmsg. Jejich význam je očividný, console znamená výstup na systémovou kozoli, volba syslog pošle zprávy do /dev/log, kmsg je uloží do jaderného bufferu zpráv a poslední volba zapisuje do /dev/log, pokud je k dispozici.

systemd.log_location – pro ty, kteří mají ambici opravovat přímo kód systemd je tento argument. Hodnota true určuje, zda se do výstupu má zahrnout i název a řádek ve zdrojovém kódu.

Ovládání jednotek

K ovládání démona systemd slouží příkaz systemctl. Ten má, mimo jiné, příkazy pro manipulaci s jednotkami, které nahrazují /etc/init.d/foo (status|start|stop|restart|...). Prostým napsáním příkazu systemctl získáme seznam právě běžících jednotek

$ systemctl | head
dev-hugepages.automount   loaded active running       Huge Pages File System Aut
dev-mqueue.automount      loaded active running       POSIX Message Queue File S
proc-sys...misc.automount loaded active waiting       Arbitrary Executable File 
sys-kern...ebug.automount loaded active waiting       Debug File System Automoun
sys-kern...rity.automount loaded active running       Security File System Autom
sys-devi...et-eth0.device loaded active plugged       82566DC Gigabit Network Co
sys-devi...ock-sr0.device loaded active plugged       HL-DT-STDVD-RAM_GSA-H50L
sys-devi...da-sda1.device loaded active plugged       ST3250410AS
sys-devi...da-sda2.device loaded active plugged       ST3250410AS
sys-devi...da-sda3.device loaded active plugged       ST3250410AS

Příkazem systemctl status JEDNOTKA|PID se dotazujeme na stav jednotky, nebo procesu

$ systemctl status dbus.service
dbus.service – D-Bus System Message Bus
      Loaded: loaded (/lib/systemd/system/dbus.service)
      Active: active (running) since Thu, 17 Feb 2011 16:12:34 +0100; 2 weeks and 5 days ago
     Process: 762 ExecStartPre=/bin/rm -f /var/run/dbus/pid (code=exited, status=0/SUCCESS)
     Process: 755 ExecStartPre=/bin/dbus-uuidgen --ensure (code=exited, status=0/SUCCESS)
    Main PID: 764 (dbus-daemon)
      CGroup: name=systemd:/system/dbus.service
              ├  764 /bin/dbus-daemon --system --address=systemd: --nofork --systemd-activation
              ├ 1085 /usr/lib/polkit-1/polkitd
              ├ 3604 /usr/lib/upower/upowerd
              ├ 3640 /usr/lib/udisks/udisks-daemon
              ├ 3647 udisks-daemon: polling /dev/sr0
              └ 3806 /usr/lib/rtkit/rtkit-daemon

K příkazu status existuje ještě ekvivalentní příkaz show, který je vhodnější pro používání ve skriptech, protože jeho výstup je součástí interface stability promise.

$ systemctl show dbus.service | head
Id=dbus.service
Names=dbus.service
Requires=dbus.socket basic.target
WantedBy=multi-user.target
Conflicts=shutdown.target
Before=earlyxdm.service xdm.service cups.service bluez-coldplug.service haldaemon.service shutdown.target multi-user.target pm-profiler.service single.service
After=dbus.socket syslog.target basic.target
Description=D-Bus System Message Bus
LoadState=loaded
ActiveState=active

A další možností, jak se dotazovat na stav jednotky (jednotek) je příkaz is-active, který vrací 0, pokud je jednotka (jednotky) aktivní a 1 v opačném případě. Bez přepínače --quiet rovněž vypisuje aktuální stav.

$ systemctl is-active sshd.service; echo $?
active
0
$ systemctl is-active --quiet sshd.service; echo $?
0

Příkazy start|stop|restart|try-restart spouští|zastavují|restartují jednotky. Rozdíl mezi restart a try-retart je v tom, že druhý příkaz skončí chybou, pokud jednotka předtím neběží. Příkaz reload požádá démona o znovu nahrání konfigurace. Složitě znějící příkaz reload-or-restart (reload-or-try-restart) zkusí požádat příslušného démona o znovu nahrání konfigurace a pokud to nepodporuje, pak jej restartuje.

Úrovně běhu

Koncept úrovní běhu (runlevel) je asi nejčastěji nahrazovanou částí sysvinit. Z čehož mají pochopitelnou radost především uživatelé, kteří přecházejí ze sysvinit. Dobrá zpráva je, že koncept úrovní běhu je zabudován i v systemd a to prostřednictvím jednotek .target.

Existují jak kompatibilní názvy – runlevel5.target, tak i ty smysluplné, jako multi-user.target, což je ekvivalent runlevel3.target, nebo graphical.target, což je runlevel5.target. Pro změnu je možné použít kompatibilní příkaz telinit, nicméně většina dnešních systémů umožňuje paralelní instalaci sysvinit a systemd, tudíž je lepší si pamatovat nativní příkaz systemctl isolate graphical.target

Příkaz isolate spustí zadané jednotky včetně jejich závislostí a ukončí všechny ostatní. Výchozí úroveň je potom uložena v souboru /etc/systemd/system/default.target, což je symbolický odkaz na jednotku, která bude spuštěna při startu. Změnou tohoto odkazu ovlivníme výchozí úroveň pro příští start.

Problém nastává v okamžiku, kdy potřebujeme zjistit úroveň běhu a to proto, že typ .target je daleko obecnější, než úroveň běhu. Tak například je možné vytvořit úrovně, které neodpovídají žádnému klasickému číslu, anebo může být v jeden čas aktivních vícero jednotek.

systemctl list-units --type=target
UNIT                      LOAD   ACTIVE SUB    JOB DESCRIPTION
basic.target              loaded active active     Basic System
cryptsetup.target         loaded active active     Encrypted Volumes
dbus.target               loaded active active     D-Bus
getty.target              loaded active active     Login Prompts
graphical.target          loaded active active     Graphical Interface
local-fs.target           loaded active active     Local File Systems
multi-user.target         loaded active active     Multi-User
network.target            loaded active active     Network
remote-fs.target          loaded active active     Remote File Systems
sockets.target            loaded active active     Sockets
swap.target               loaded active active     Swap
sysinit.target            loaded active active     System Initialization

dokáže zjistit, které tyto jednotky jsou aktuálně aktivní.

Jaderný parametr systemd.unit umožňuje spustit systém s jiným než výchozím cílem. Vhodné pro emergency.target, i když uživatelé se smyslem pro napětí mohou zadávat ctr-alt-del.target nebo halt.target. Nicméně nejčastěji budou uživatelé zadávat

• emergency.target – nastartuje shell na hlavní konzoli – obdoba init=/bin/bash
• rescue.target (runlevel1.target) – nastartuje minimální systém a otevře konzoli

Závěrem

V dnešním díle jsme zjistili, které typy jednotek systemd podporuje. Jakým způsobem ovládat a zjišťovat stav jednotek. Jak funguje ekvivalent úrovní běhu u systemd. Následující část bude věnována speciálním jednotkám systemd, takže se dozvíte, co znamenají všechny ty rescue.target a podobně. Navíc se ponoříme hlouběji do systému závislostí systemd.

       

Komentáře

[tomas]

Diky za clanek, zkousel si to merit, o kolik je to v realu rychlejsi nez klasicky init?

[Ja]

Zkoušel jsem F15 a startovala o dost pomaleji než F14, ale pořád je to beta a bylo to výchozí nastavení služeb, tak to snad nebude tak zlé.

[petr_p]

Beta u Fedory znamená, že do repozitářů jdou jen aktualizace, které představují opravy zásadních problémů nebo implementace funkcí slíbených pro ostrou verzi, ale ještě nedokončených. Takže rychlostní překvápka ve stylu Mozilly, která ostré verze zryhluje vypnutým laděním, se ve Fedoře čekat nedají.

Pokud by někdo čekal úžasné zrychlení díky parelelnímu startu, tak: (1) na to nemusel čekat na systemd, upstart (nebo jiné systémy v jiných distribucích) jej také umí, a (2) teprve minulý týden byla schválená specifikace, jak psát init scripty pro systemd ve Fedoře, takže drtivá většina démonů se stejně startuje starým LSB skriptem a démoni nejsou upraveni na odložený start přes socket.

Takže suma sumárum si v F15 změříte režii samotného systemd. Což ale vůbec není špatná věc.

[maleprase]

(2) teprve minulý týden byla schválená specifikace, jak psát init scripty pro systemd ve Fedoře, takže drtivá většina démonů se stejně startuje starým LSB skriptem

to sice ano ale systemd vytvari ze starych initskriptu interne unity (.service) - na zaklade LSB v hlavicek a s ExecStart= vedoucim na ten skript - a ty pak pousti paralerne a neceka na ne

realny problem s pomalejsim startem jsou ruzne "race condition" plynouci prave z masivni pararelizace

[Libor Chocholaty]

Nechapu, jak muze masivni paralelizace zpusobit problemy s pomalejsim startem...

[maleprase]

napriklad kdyz je sluzba zavisla na urcitem prostredi a to prostredi nastavuje sluzba ktera je poustena zaroven s ni. pak ta se ta zavisla muze dostat do stavu kdy ceka na prostredi ale protoze ji ta druha neupozorni tak dojde k 3minutovemu timeoutu ...

[michich]

Není obvyklé, že by to bylo o dost pomalejší. Mohlo se jednat o bug, kdy vytimeoutovala nějaká služba. V takových případech je nejlepší nabootovat s "log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg" a nahlásit chybu s přiložených výpisem z dmesg.

[mam]

mne sa start oproti f14 zrychlil vo f15 so systemd na asi 23 sekund.

[jsimitseo]

검증된 파워볼사이트 를 찾으신다면 eos파워볼사이트 가 있는 파워볼사이트추천 에서 파워볼 을 즐기시길 바랍니다. 5년 이상 운영된 메이저업체 이며 지금까지 많은분들께 사랑받은 안전한파워볼사이트 입니다. 파워볼사이트

[Daniel Tihelka]

Díky za článek. systemd se zájmem sleduji skoro od začátku jeho existence, zatím jsem ale neměl odvahu jej vyzkoušet.

Chtěl bych se proto zeptat publika, především Gentooistů, jestli máte někdo zkušenosti s instalací systemd na Gentoo a jak to probíhalo - rozbilo se moc věcí nebo byl základní přechod víceméně bez problémů? Na co si dát pozor?

Díky všem, Dan.

[Marián Kyral]

Gentoo mám, systemd se mi celkem zamlouvá, ale zatím nemám odvahu to zkoušet. Přece jen, je to dost citlivá věc a není moc času na hraní. Takže si ještě nějakou dobu (rok/dva) počkám.

[Daniel Tihelka]

Ano, jsem ve stejném stavu

[kralyk z abclinuxu]

Koukal jsem, že v Archu už je Systemd v [community], máte s tím někdo zkušenostě?

[Xerces]

Není někde porovnání s runit od DJB?

[Petr Ježek]

Mám, používám, stačí upravit kernel line v Grub (Grub2) dle dobře zpracované wiki. Efekt u mne není příliš patrný, subjektivně snad mírné zrychlení, funkčnost plně zachována.

[Petr Ježek]

Ech. to byla odpověď kralykovi

[kralyk z abclinuxu]

Díky

[michich]

Možná se mýlím, ale z toho, co jsem si přečetl o runit, jsem pochopil, že dokáže spravovat pouze slušně vychované služby, které:

• se samy nedaemonizují, jinak by runitu utekly z dohledu;
• při startu důkladně zkontrolují, zda mají splněny všechny závislosti, a pokud ne, tak ihned skončí. (Počítá se s tím, že je runit o chvíli později zkusí spustit znovu předpokládaje optimisticky, že mezitím ty závislosti nastartovaly.)

Přijde mi to méně univerzální a víc jako hack.