abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 22:00 | Nasazení Linuxu
Stabilní aktualizace Chrome OS 69 (resp. Chromium OS), konkrétně 69.0.3497.95, přináší mj. podporu linuxových aplikací. Implementována je pomocí virtualizace, a proto je tato funkce také omezena na zařízení s dostatkem paměti a podporou hardwarové akcelerace, tudíž nejsou podporovány chromebooky s 32bitovými architekturami ARM, či Intel Bay Trail (tzn. bez Intel VT-x).
Fluttershy, yay! | Komentářů: 0
včera 21:32 | Zajímavý projekt
Došlo k uvolnění linuxové distribuce CLIP OS, vyvíjené francouzským úřadem pro kybernetickou bezpečnost ANSSI, jako open source. Vznikla za účelem nasazení v úřadech, kde je potřeba omezit přístup k důvěrným datům. Je založená na Gentoo.
Fluttershy, yay! | Komentářů: 0
včera 16:00 | Komerce

Zjistěte více o bezpečné a flexibilní architektuře v cloudu! IBM Cloud poskytuje bezpečné úložiště pro Vaše obchodní data s možností škálovatelnosti a flexibilitou ukládání dat. Zároveň nabízí prostředky pro jejich analýzu, vizualizaci, reporting a podporu rozhodování.

… více »
Fluttershy, yay! | Komentářů: 12
včera 12:22 | Nová verze

V dubnu letošního roku Mozilla představila webový prohlížeč pro rozšířenou a virtuální realitu Firefox Reality (GitHub). V úterý oznámila vydání verze 1.0. Ukázka na YouTube. Firefox Reality je k dispozici pro Viveport, Oculus a Daydream.

Ladislav Hagara | Komentářů: 2
včera 12:00 | Komunita

V srpnu loňského roku společnost Oracle oznámila, že Java EE (Enterprise Edition) bude uvolněna jako open source. O měsíc později bylo rozhodnuto, že tato open source Java EE bude přejmenována a předána Eclipse Foundation. Nové jméno bylo oznámeno v únoru letošního roku. Z Java EE se stala Jakarta EE. Eclipse Foundation včera oznámila dosažení dalšího milníku. Zdrojové kódy aplikačního serveru GlassFish jsou již k dispozici v git repozitářích Eclipse Foundation (GitHub).

Ladislav Hagara | Komentářů: 0
19.9. 23:55 | Komunita

LTS (Long Term Support) podpora Ubuntu 12.04 LTS (Precise Pangolin) skončila po 5 letech od jeho vydání, tj. v dubnu 2017. V březnu 2017 ale Canonical představil placenou ESM (Extended Security Maintenance) podporu, díky které je Ubuntu 12.04 podporováno do dubna 2020. Dnes Canonical potvrdil ESM podporu také pro Ubuntu 14.04 LTS (Trusty Tahr), jehož LTS podpora skončí v dubnu 2019.

Ladislav Hagara | Komentářů: 0
19.9. 15:00 | Nová verze

Byla vydána verze 3.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí HTML, CSS a JavaScriptu Electron (YouTube, GitHub). Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.

Ladislav Hagara | Komentářů: 0
19.9. 14:44 | Nová verze

Po půl roce vývoje od vydání verze 6.0.0 byla vydána verze 7.0.0 překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, clang-tools-extra a LLD.

Ladislav Hagara | Komentářů: 0
19.9. 13:44 | Nová verze

Byla vydána verze 3.0.0 knihovny pro vykreslování grafů v programovacím jazyce Python Matplotlib (Wikipedie, GitHub). Přehled novinek a galerie grafů na stránkách projektu. Zrušena byla podpora Pythonu 2.

Ladislav Hagara | Komentářů: 0
19.9. 00:22 | Komunita

V Norimberku probíhá do pátku ownCloud conference 2018, tj. konference vývojářů a uživatelů open source systému ownCloud (Wikipedie) umožňujícího provoz vlastního cloudového úložiště. Přednášky lze sledovat online. Videozáznamy jsou k dispozici na YouTube. Při této příležitosti byl vydán ownCloud Server 10.0.10. Z novinek lze zdůraznit podporu PHP 7.2. Vydán byl také ownCloud Desktop Client 2.5.0. Vyzkoušet lze online demo ownCloudu.

Ladislav Hagara | Komentářů: 1
Na optické médium (CD, DVD, BD aj.) jsem naposledy vypaloval(a) data před méně než
 (13%)
 (15%)
 (20%)
 (23%)
 (25%)
 (4%)
 (1%)
Celkem 377 hlasů
 Komentářů: 33, poslední 16.9. 11:55
Rozcestník

Systemd – vlastnosti a schopnosti

23. 3. 2011 | Michal Vyskočil | Systém | 11859×

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. Dnešní díl bude o přístupu systemd k problematice a vlastnostech celého systému.

Obsah

Rethinking PID 1

link

Koncem dubna 2010 Lennart Poettering (možná znáte jeho ostatní projekty – PulseAudio a Avahi) napsal blog Rethinking PID 1. V něm oznámil vznik svého projektu systemd, který mění způsob nazírání na init, čili procesu s PID 1.

Jako hlavní znak dobrého systému Lennart uvádí rychlý start, což je poněkud nešťastné, protože odvádí pozornost od inovativního návrhu a způsobu fungování. Ale budiž.

Skutečně paralelní start démonů

link

Problém paralelizace řeší prakticky každá alternativa, nicméně v praxi to pak dopadá následovně – chceme spustit libvirtd a X11. Oba nicméně potřebují (potřebovali) HAL, který ovšem potřebuje D-BUS démona, který potřebuje spuštěný syslogd. Celé to obrovské úsilí o paralelizaci skončilo tím, že první tři služby se zavádějí postupně a teprve poslední dvě vedle sebe.

Ve snaze odstranit tyto sériové závislosti se systemd dívá na problematiku jinak. Co je skutečně potřeba pro sériové spouštění démonů? Klasické unixové démony obvykle vyžadují přítomnost služby poskytované jiným démonem, což je typicky AF_UNIX socket někde v souborovém systému. Ale může to být i AF_INET, anebo speciální zařízení. Takže třeba D-BUS klient potřebuje unix socket /var/run/dbus/system_bus_socket, k němuž by se mohl připojit a démon zapisující do systémového logu zase očekává socket /dev/log.

Takže, pokud se podaří tyto sockety vytvořit dříve, můžeme oba dva démony jednoduše spustit současně, ačkoli jsou jejich závislosti sériové. Naštěstí v unixových systémech je to prosté – můžeme vytvořit socket před startem vlastního démona a potom mu jej předat prostřednictvím volání exec(). V případě, že nějaký jiný démon potřebuje s takovým socketem pracovat, pak je prostě přidán do fronty požadavků a pozastaven do doby, než se spustí démon, který takové požadavky akceptuje.

Díky tomu systemd nevyžaduje explicitní uvádění závislostí. Celá tato mašinérie jednoduše využívá existující kód v jádře a jako vedlejší efekt nabízí opravdu masivně paralelní start všech služeb.

Odložené spuštění

link

Alternativní a prakticky nevyužívaná strategie pro zkrácení doby startu je odložení doby startu démona až na doby, kdy bude existovat první požadavek na její spuštění. Tento přístup byl implementován desítky let jako démon (x)inetd, ale jako samotný init systém se neujal.

V praxi existuje mnoho případů, kdy není nezbytné startovat služby při startu. Tiskový démon cups není nezbytné spustit dříve, než přijde první požadavek na tisk. Bluetoothd není třeba, pokud neexistuje potřeba komunikovat přes bluetooth, avahi není nutné, když není systém připojen k síti a dokonce ani ssh démona nemusíme spouštět, pokud se na něj zrovna nechce někdo připojit.

Princip, na kterém systemd provádí masivní paralelní start, lze jednoduše použít i pro spouštění na požádání – kdykoli systemd detekuje, že někdo chce použít daný socket, automaticky nastartuje patřičnou službu. Tím jsou splněny dva předpoklady rychlého startu – spouštět služby co nejvíce paralelně a rovněž spouštět pouze ty, které jsou skutečně potřeba. Mimochodem, stejně tak funguje i launchd systému OS X, který byl, jak Lennart uznává, zdrojem inspirace pro systemd.

Stejná logika jde aplikovat i na moderní desktopové démony jako Avahi, bluetoothd a podobně, které namísto socketu komunikují přes D-BUS. Jeho obslužný démon totiž umí aktivovat služby na požádání – tedy spustit obslužného démona až v okamžiku, kdy je proveden první požadavek na jeho rozhraní. Stejně jako v případě socketů jsou dotazy řazeny do fronty a zpracovány v okamžiku, kdy obslužný démon naběhne.

Čili tento přístup umožňuje se nejenom vyhnout zbytečným explicitním závislostem, serializaci při startu – navíc implicitně dokáže spouštět služby na požádání. Slovy Lennarta:

And if that's not great, then I don't know what is great!

A pokud to není skvělé, pak už nevím, co je skvělé!

Paralelní souborové operace

link

Samotné spouštění démonů je pouze část zavádění, která neběží paralelně a kde se čeká na doběhnutí jedné úlohy po druhé. Nejčastěji jde o souborové operace jako připojování disků, jejich kontrola a kontrola kvót. Teprve po této, často zdlouhavé operaci, se pokračuje v samotném zavádění.

Stejně jako v případě socketů a D-BUS, nástroje pro vyřešení takového problému dávno existují. Jak Lennart píše ve svém blogu, tak Harald Hoyer přišel s řešením v podobě autofs. Nahradit skutečné přípojné body (mount points) systémem autofs a potom jednoduše čekat až nějaká aplikace zavolá open() na daný prostor, čímž se její běh přeruší a požadavek opět umístí do fronty, systém mezitím provede kontrolu integrity i uživatelských kvót, přípojný bod nahradí skutečným a probudí doposud zablokovanou aplikaci. Systém autofs navíc dokáže zpět propagovat chyby, pokud nemohl být daný systém z nějakého důvodu připojen. Pochopitelně takové odložené připojení nemá smysl pro kořenový adresář, nebo pseudosystémy jako procfs a sysfs.

Deklarativní popis init skriptů

link

Skriptovací init skripty jsou rychlé a pomalé zároveň. Je rychlé je napsat, ale jsou velice pomalé ke spouštění. V zásadě nezáleží na tom, zda používáme těžkotonážní /bin/bash, nebo odlehčenou alternativu, zavádění bude vždy pomalé. Lennart uvádí, že na jeho systému zavádění systému znamená 77 volání grep, 92 volání awk, 23 cut a 74 sed. Což znamená pro každý takový příkaz opakování fork/exec, nahrání dynamických knihoven, kontrolu lokalizace, parsování argumentů příkazové řádky a podobně. Navíc jsou init skripty velice křehké, citlivé na odchylky v nastaveném prostředí a podobně.

Poměrně zajímavou metrikou toho, kolik procesů muselo naběhnout jenom pro zavádění systému je nabootovat, přihlásit se a v terminálu napsat echo $$ pro zjištění PID aktuálního shellu. Lennart uvádí Linux: 1823, OS X 154.

Naštěstí velká část logiky init skriptů se opakuje, takže může být snadno reimplementovaná v C a poskytována samotným systemd. Systemd nabízí deklarativní popis init skriptu, který je snadné napsat, množství výplňového kódu a počet chyb je redukován. Navíc, nejde o nijak nový princip, (x)inetd obsahují právě takový deklarativní způsob psaní služeb. Pro případy, kdy je logika spouštění příliš složitá na deklarativní popis je možné se v něm odkázat na skript, který dané spuštění vykoná.

Jako vedlejší efekt – protože se o spuštění démona stará přímo systemd a ne nějaký shellový kód, není potřeba používat triky jako double-fork pro vyvázání se z aktuálního terminálu. Když už nic, tak procesy spuštěné systemd mají jako rodiče přímo PID 1. Dobrý démon pro systemd má pouze obslužnou smyčku, loguje do stderr a nepoužívá magii, takže v konečném důsledku vypadá více jako běžná aplikace, kterou je snadné ladit.

Ačkoli jsme už na konci našeho původního seznamu, Lennart jde ještě dál a přidává další důležitou vlastnost pro dobrý init systém.

Sledování procesů

link

Dobrý systém spouštějící služby je také musí umět sledovat. Restartovat, pokud spadnou a sesbírat užitečné informace získané z pádu, poskytnout je systému pro práci s core soubory a zapsat zprávu do systémového logu.

Také musí být schopen kompletně vypnout danou službu, což nemusí být zcela jednoduché. V unixu stačí udělat dvojitý fork a tím se dostat z dosahu kontroly rodičovského procesu, což je mimochodem přesně způsob, jak pracují démoni. Takže splašený cgi skript nemusí být ukončen prostým ukončením Apache.

Naštěstí kernel obsahuje potřebnou technologii – Control Groups, která byla do jádra přidána pro potřeby kontejnerů a nastavování limitů pro jaderné prostředky pro určité skupiny procesů, na rozdíl od tradičního setrlimit vázaného na proces. Výhodou je, že neprivilegované procesy se ze své kontrolní skupiny nemohou dostat. Tím je pro systemd velice snadné procesy kontrolovat. Pro každý proces je jeho skupina viditelná v /proc/$PID/cgroup a navíc jsou skupiny procesů dostupné v sysfs.

Ovládání prostředků

link

A v neposlední řadě, pokud už init systém dokáže procesy sledovat, mohl by umět i kontrolovat jejich prostředí. Klasické init skripty se obvykle omezují na omezení v podobě uživatele a skupiny, vzácně pak nastavují limity přes ulimit/setrlimit. Schopnosti Linuxu, jak nastavit prostředky, jsou mnohem větší – je možné nastavit plánovač procesoru nebo IO, capability bounding set, CPU affinity a podobně.

Například spouštění updatebIOPRIO_CLASS_IDLE bude mít pozitivní důsledky na interaktivitu systému, protože požadavky tohoto procesu se začnou vykonávat pouze v případě, že neexistují jiné.

Ostatní vlastnosti

link
  • Kompatibilní /dev/initctl, které poskytuje očekávané rozhraní pro shutdown, poweroff a ostatní podobné příkazy.

  • Kompatibilní s utmp a wtmp, přestože je autor označuje za „crufty“, příkazy jako who budou pracovat i se systemd.

  • Podpora pro restart procesu init. Stav démonu je před ukončením serializován a poté obnoven. Tímto způsobem jsou podporovány mimo jiné updaty démona bez nutnosti restartu. I v průběhu restartu jsou všechny sockety a jiné zdroje dostupné, takže klienti nezjistí, že se init systém restartoval. Navíc kód pro restart démona je prakticky totožný s kódem pro znovu nahrání konfigurace.

  • Transakční systém – při požadavku na start jednotky se nejprve vyhodnotí závislosti, provede se detekce případných cyklů a jejich vyřešení odstraněním volitelných závislostí a pokud vše proběhne v pořádku, přidá se požadavek na spuštění jednotek do fronty požadavků.

  • C implementace rozličných služeb vykonávaných v průběhu zavádění jako připojení /sys a /proc, nastavení hostname, nebo síťového rozhraní lo.

Status update

link

S tím, jak je systemd navržen a funguje, je jasné, že existuje spousta míst, kde se jeho funkce překrývá s funkcí jiné služby. A také to, že existuje spousta nových vlastností, které nebyly v původním článku zmíněny, nebo prostě byly přidány až později, anebo byly zmíněny, ale nedokončeny. Proto vydal Lennart (zatím) dva články s názvem Status Update, kde ukazuje změny, které se v mezičase udály.

  • Další speciální služby – .timer pro časové spouštění ve stylu cron. Služba .swap, která připojuje oddíly a soubory pro swap na požádání. A .path pro aktivaci služeb závislých na existenci/vytvoření nějakého adresáře, či souboru.

  • Podpora pro značky SELinux, auditd a TCP wrappery. Nástroj systemd-cgl pro vykreslování stromu procesů. Kód, který automaticky zavolá getty nad sériovým portem, pokud je jaderná konzole přesměrovaná na sériové rozhraní. Spousta patchů v nejrůznějších upstream projektech pro podporu socketové aktivace a přidávání .service souborů. Podpora nejrůznějších jaderných virtuálních souborových systémů prostřednictvím autofs – po prvním požadavku na čtení z dané části je nahrán specifický modul a systém připojen.

  • Integrace s PAM, takže systemd při spuštění služby pod jiným uživatelem vytvoří a ukončí běžnou pam session. Speciální PAM modul systemd přiřazuje procesy každé takové session do vlastní control group, takže všechny takové procesy jsou (respektive mohou být) po odhlášení ukončeny, bez ohledu na to, zda se nejmenují třeba screen.

  • Integrace s dbusd, takže všechny požadavky na aktivaci služeb jsou předávány systemd. Díky tomu lze aplikovat všechna možná nastavení prostředí, která systemd umožňuje. Spolu s tím bylo plně dokončeno D-BUS rozhraní samotného systemd.

  • Systemd vytváří /dev/log ihned po startu a propojuje jej s kernel log buffer (kmsg). Hned po startu skutečného syslogd je /dev/log přesměrován na tohoto démona. Protože syslogd po svém startu jako první věc zapíše kmsg do souboru, neztratí se ani jedna zpráva. Navíc, pokud dojde k pádu logovacího démona, /dev/log je opět přesměrován do jaderného bufferu. A v neposlední řadě – systémy, které negenerují spousty událostí (typicky embeded), mohou syslogd úplně vynechat a mít vše ukládané v jaderném bufferu zpráv.

  • systemd obsahuje minimální implementaci readahead založenou na fanotify(), fadvise() a mincore(). Podporuje jak SSD, tak klasické rotující disky. Výkonový zisk pro rychle startující systémy je malý, ale změnu pocítí především uživatelé těch starších a pomalejších.

  • Inicializace systémových locales přímo systemd.

  • Nativní podpora pro /etc/crypttab, která umožňuje připojovat disky LUKS/dm-crypt jak při startu, tak v průběhu života systému. Podpora různých klientů pro zjišťování hesel – buď přes konzoli nebo Plymouth dialog nebo v grafickém prostředí pomocí wall či Gnome agenta.

Závěrem

link

Důvodem, proč je systemd současná „hvězda“ init systémů, je fakt, že se nejedná pouze o yet another sysvinit alternative. Vlastnosti jako socket/path based aktivace služeb, kontrola prostředí a integrace se spoustou dalších technologií, supervize procesů, které systemd nabízí, jsou alespoň v linuxovém světě jedinečné.

Lennart dále uvádí, že stejně jako launchd, může systemd nahradit současné aplikace pro správu uživatelských relací, jako gnome-session nebo kdeinit. Kontrola stavu procesů, paralelní spouštění a schopnost ukládat aktuální stav a zase jej obnovit – to vše mají oba typy programů společné.

V dalším díle se podíváme systemd na zoubek o něco více.

       

Hodnocení: 100 %

        špatnédobré        

Nástroje: Tisk bez diskuse

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

23.3.2011 10:08 Xerces
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
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.
23.3.2011 18:06 Jan Molič
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
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ě).
23.3.2011 19:55 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
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.

12.5.2011 07:22 Xerces
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
Díky za názor. Na OpenRC se podívám, nějak mne minul.
23.3.2011 10:55 ext3fs
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
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 avatar 23.3.2011 12:58 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
1/ Pad poznaji tak ze proces skonci. Ukonceni poznaji tak ze jsou pozadani aby proces ukoncili. sysv init to dela stejne.
"2^24 comments ought to be enough for anyone" -- CmdrTaco
23.3.2011 14:53 ext3fs
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
Ale co kdyz proces neni ukoncen radnou cestou ale spadne? Treba na nedostatek pameti. Jak vi, ze jej maji znovu startovat?
23.3.2011 13:39 Karel Zak | blog: kzak
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
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 avatar 23.3.2011 15:23 D.A.Tiger | skóre: 8 | Brno
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
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í...

Radost z toho, že někdo objeví něco nového, je omyl starý 6000 let... (Jean Paul) | anthill inside
23.3.2011 16:32 Boris Dušek | skóre: 22 | blog: everything
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
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)
vim ~/.emacs
24.3.2011 11:42 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
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.
When your hammer is C++, everything begins to look like a thumb.
24.3.2011 12:15 maleprase | skóre: 28
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
V praxi tak bude na jednom počítači systemd s pid 0

init ma pid 1
24.3.2011 13:21 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
Jasně - pitomý překlep :-D
When your hammer is C++, everything begins to look like a thumb.
23.3.2011 21:55 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
Dík za zajímavý článek.
24.3.2011 10:25 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
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?
24.3.2011 12:36 maleprase | skóre: 28
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
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?
24.3.2011 13:20 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
Rozbalit Rozbalit vše Re: Systemd – vlastnosti a schopnosti
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č.
When your hammer is C++, everything begins to look like a thumb.

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.