Systemd – vlastnosti a schopnosti (diskuse)

[Xerces]

Díky za článek, slyšel jsem o tom ale zatim neměl čas hledat relevantní informace. Nápady pěkný ale doufám, že se to neprosadí. Příjde mi to dost těžkotonážní. Jsem sám, nebo to taky někomu připomíná runit od DJB? Ano oproti runitu to má daleko více možností. Runit tuším spoléhá na to že služba selže a opakovaně ji zkouší nahazovat čímž trošku "plýtvá" ale paměťová nenáročnost a jednoduchý princip si myslím hovoří proti systemd.

[Jan Molič]

Runit je fajn (mám na mysli Runit Gerry Papeho, to jest přepracováné původní daemontools od DJB). Teprve v praxi se ukazují nedostatky. Samozřejmě v porovnání s klasickým initem SysV u mne vítězí na celé čáře, ale z dnešního pohledu existují lepší inity (například OpenRC).

Runit nemá žádný systém závislostí; ve stylu DJB dělá jen to, co má dělat - inicializaci systému. Vše se spouští paralelně naráz, a tak ho nelze použít pro nízkoúrovňovou inicializaci ve smyslu fsck disků, apod. Snažil jsem se sice svého času vytvořit jakousi nadstavbu, ale vnesl jsem do toho akorát složitost.

Největším problémem, s nímž se člověk u daemontools/runitem setká, je vytuhnutí služby kvůli nefunkčnímu loggeru. Vzhledem k tomu, že služba může pomocí provázání svého stderroru logovat přímo do logger daemona, tak jeho nefunkčnost způsobí zatuhnutí služby. Jde o to, že rouru (stderr), do níž služba posílá hlášky, logger nečte a nakonec se roura zaplní - služba, tj. zapisovatel, vytuhne. Bohužel se stává, že nějaká služba produkuje málo hlášek na stderr, takže zaplnění roury může trvat klidně měsíc - a vy pak nechápete, proč to z ničeho nic přestalo jít... Logovací daemon přitom nenastartuje kvůli tak banální věci, jako třeba špatným právům cílového adresáře. Samozřejmě je možné sledovat funkční loggery skriptem, ale už je to zase nějaká složitost navíc.

Filozofie DJB je skvělá, v praxi však plodí složitost. Nejjednodušší funkce totiž obvykle nestačí a je potřeba je dodat externě a nestandardně (což je ona složitost). Přesto DJB uznávám. Je sice extremista, ale všem ukázal, že atomizovaný Qmail je lepší než molochoidní Sendmail. Střední cestou mezi atomizací a molochem je pluginová architektura. Proto osobně dávám přednost Postfixu před Qmailem, OpenRC před Runitem. Je otázkou, zda systemd je moloch, či se poučil od DJB a činnosti separoval (alespoň interně).

[petr_p]

vytuhnutí služby kvůli nefunkčnímu loggeru

To mi povídejte. Dneska jsem aktualizoval Fedoru-16 a když yum nainstaloval první balíček, tak se zasekl. Tak jsem ho zabil a znovu. Ukázalo se, že se zablokoval v send(2) nad socketem /dev/logger. V tu ránu se nedalo přihlásit přes SSH, nešlo udělat su, dokonce systemctl (nástroj pro ovládání systemd) dokázal rsyslogd zabít až na po páté. rsyslogd mezi tím spal v pthread_cond_wait(), takže se neobtěžoval číst protokol.

[Xerces]

Díky za názor. Na OpenRC se podívám, nějak mne minul.

[ext3fs]

Zajimalo by mne jak tato a podobne aplikace provadi nasledujici veci:

1/ jak rozpoznaji pad procesu od ukonceni (kdyz nejsou rodicovsky proces)

2/ odkud sbiraji informace o procesech mimo z /proc/PID/

Je mozne tohle resit i ciste v userspace?

[rADOn]

1/ Pad poznaji tak ze proces skonci. Ukonceni poznaji tak ze jsou pozadani aby proces ukoncili. sysv init to dela stejne.

[ext3fs]

Ale co kdyz proces neni ukoncen radnou cestou ale spadne? Treba na nedostatek pameti. Jak vi, ze jej maji znovu startovat?

[Karel Zak]

1/ prave pouziva cgroups kde pokud je skupina prazna tak se zavola release_agent

   $ cat /sys/fs/cgroup/systemd/release_agent
   $ cat /sys/fs/cgroup/systemd/systemd-1/*.service/notify_on_release

2/ /proc a /sys/fs/cgroup/systemd

Prave cgroups umoznuje definovat cely strom procesu a systemd (a i admin systemu) ma pak pekny prehled o tom jake procesy jsou kde (v jake skupine).

viz. treba

    $ systemctl status dbus.service
    $ systemd-cgls

[D.A.Tiger]

Vypadá to zajímavě.

Nebylo by špatné, když už INIT systém řeší start služeb/demonu při startu systému, vložit do toho ještě funkčnost centrálního nastavení a startu aplikací při loginu. Osobně to řeším tak, že mám jednoduchou aplikaci, která se o to stará a přidávám do nastavení autostartu prostředí, která používám, pouze odkaz na tuto aplikaci. jenže to je taková z nouze cnost...

Je hezké že jsou procesy sledovány a v případě, že ztratí své rodičovské procesy, jsou automaticky ukončovány procesem init. Ale občas by se hodila přesně opačná vlastnost - při startu dané aplikace ji vyvázat (bez nutnosti využívání nějakých triků, třeba i s tím, že by bylo nutné zadat nový rodičovský proces... ). Některá prostředí to řeší alespoň tak, že na pozadí spustí samostatný proces, kterému jsou potom předávány požadavky na spuštění konkrétní aplikace a které jsou jejich rodičovskými procesy. Jenže ani to není úplně ideální...

[Boris Dušek]

Vypadá to zajímavě.

Nebylo by špatné, když už INIT systém řeší start služeb/demonu při startu systému, vložit do toho ještě funkčnost centrálního nastavení a startu aplikací při loginu.

launchd to řeší, systemd se inspiroval u launchd => asi to systemd bude řešit taky (myslím, že jsem to i explicitně četl, ale nechci to teď hledat)

[Michal Vyskočil]

Systemd podporuje režimy --system a --user, přičemž ten druhý je míněn jako náhrada za dnešní správce uživatelských relací. V praxi tak bude na jednom počítači systemd s pid 0 i další uživatelské instance.

[maleprase]

V praxi tak bude na jednom počítači systemd s pid 0

init ma pid 1

[Michal Vyskočil]

Jasně - pitomý překlep

[kralyk z abclinuxu]

Dík za zajímavý článek.

[kralyk z abclinuxu]

Jedna věc mi není jasná. U toho spouštění služeb na požádání, jestli to dobře chápu, tak systemd vytvoří socket dopředu a službu spustí, až když se někdo chce na ten socket připojit. Odkud ale systemd ví, jak ten socket vytvořit - s jakými parametry (port, adresa, ...)?
Třeba u takovýho http serveru je tohle záležitost konfigurace http deamona, ne?

[maleprase]

systemd se to dozvi z .socket souboru, napr. pro dovecot:

[Socket]
#dovecot expects separate IPv4 and IPv6 sockets
BindIPv6Only=ipv6-only
ListenStream=0.0.0.0:143
ListenStream=[::]:143
ListenStream=0.0.0.0:993
ListenStream=[::]:993

daemon potom vubec port neotvira, pripravi ho systemd, nastavi procesu promenne prostredi LISTEN_PID a LISTEN_FDS a "posle" ho demonovi s exec-em.

demony pak nekonfigurujes pres jejich vlastni konfigurak ale pres konfiguracni soubory initu. vyhoda?

[Michal Vyskočil]

Parametry jsou popsány v .socket jednotkách. Navíc, pokud konfigurujeme nastavení takto externě, nemusí se o to běžící proces nijak zajímat, protože ten pouze dostane už nastavený popisovač.