Portable Services se systemd 239

Před týdnem vydaná verze 239 správce systému a služeb systemd přinesla podporu Portable Services. Lennart Poettering se těmto "kontejnerům" podrobně věnuje v příspěvku na svém blogu.

28.6.2018 23:44 | Ladislav Hagara | Zajímavý článek

Komentáře

[asdfasdf]

Co me na systemd pripada fakt absurdni je to, ze vubec nehlida, jestli nejaka sluzba skutecne bezi nebo ne. Dam systemctl start smtpd, ten se vysere, ale v systemctl status smtpd furt vidim jak active (running), ale skutek utek.

[x]

Mno ale tohle je Linux aneb features, features, features (developers !, developers!, developers! ...... Ballmer TM). System, vznikly jako free reimplementace komercniho Unixu aby se po letech sam narval do komercniho chrtanu, ktery ho postupne nici oslama, kteri tvrdi, ze K.I.S.S., Unix principy a podobne davno neplati

Proc neco delat jednoduse (zmenil jsem -s v konfiguraci za -v -xxxx):

$ doas rcctl start ntpd ntpd(failed) $

$ doas rcctl ls failed ntpd $

$ doas rcctl -d check ntpd doing _rc_parse_conf doing _rc_quirks ntpd_flags >-v -xxxx< doing _rc_parse_conf /var/run/rc.d/ntpd doing _rc_quirks ntpd doing rc_check (failed) $

$ rcctl get ntpd ntpd_class=daemon ntpd_flags=-v -xxxx ntpd_rtable=0 ntpd_timeout=30 ntpd_user=root $

A ano, to co popisujes jsem jiz videl prilis casto v produkci s ruznymi services vcetne tech "uz integrovanych" a nepovazuji znefunkcneni zakladnich komponent OS (ktere navic nejdou ani tak snadno detekovat) za pokrok a neco normalniho a ne tak jeste za neco za co by se melo tem firmam platit.

[x]

eh nepouzil jsem tag pro code, sry

[asdfasdf]

Vpohode, vim jak to v OpenBSD vypada . Zatim imho nejlip implementovany rc v pomeru funkcionalita/jednoduchost.

[Filip Jirsák]

Řešilo se to pod minulou zprávičkou. Systemd to hlídat umí (na rozdíl třeba od SysVinitu), a záleží jen na autorovi jednotky, zda tu možnost využije nebo ne. Systemd k tomu uživatele vede, je to standardní postup popsaný v manuálu, ale samozřejmě nemůže nikomu zabránit nacpat mezi systemd a službu nějaké shell skripty, kterými zjišťování stavu služby znemožní.

[joejoe]

A umi opravdu zjistit jestli sluzba bezi? Nebo jenom zjistuje ze je spusteny nejaky z procesu v cgroup? Osobne nemam uplne dobrou zkusenost s tim jak je tohle hlidani implementovane. Nekdy se to dostane do stavu, ze 2x posle sluzbe SIGKILL a potom smete celou cgroup. Nestastne je nastaveni timeoutu, kde poslani SIGKILL a zabiti cele cgroup jsou nasobky jednoho timeoutu. Rezim kompatibility se SYSVInit taky neni uplne dobre udelany. Pri michani "service xy action" a "systemctl action xy" dochazi k tomu, ze se to nezavola jako alias, ale dela se tam nejaka radoby chytra vec a ve vysledku neni jasne jestli proces bezi nebo ne, natoz jestli opravdu sluzba funguje.

[Filip Jirsák]

Právě že systemd (nebo jiný správce služeb) vůbec nemusí aktivně zjišťovat, jestli nějaká služba běží. Ten proces je spuštěn jako potomek systemd, takže když se proces ukončí, rodičovský proces (tedy systemd) o tom dostane od jádra zprávu. Funguje to tak ve všech POSIX kompatibilních systémech, tedy i v Linuxu.

Problém je, pokud ze systemd není spuštěn přímo proces služby, ale jen nějaký zavaděč, který se po spuštění vlastní služby ukončí. Pak systemd nemá jak zjistit, zda služba opravdu běží. RC skripty to dělají tak, že vědí (třeba ze souboru) PID té služby, a kontrolují, zda je v systému proces s takovým ID. Že ten proces už může být něco úplně jiného, než ta služba, to neřeší.

[joejoe]

nicmene to vubec neresi jestli sluzba bezi nebo ne. Napriklad webovy server podle mne bezi, kdyz odpovida na portu 443. Pokud neodpovida, tak je mi u prdele jestli existuje nejaky proces.

[Sid]

Mozno by chcelo si ujednotit rozdiel medzi monitoringom a sledovanim procesu. To je ako chciet aby systemd sledoval ci sql server odpoveda na dotaz. Init snad ma riesit pad procesu a restart (ak je to ziaduce vobec)

[mirec]

Init ako systemd musí byť zároveň schopný rozpoznať, či služba je pripravená odpovedať na požiadavky. Pri klasickom sériovom štarte so shell skriptami na tom až tak nezáleží pretože každá služba sa spúšťa samostatne a kontrola sa robí rovno shell skriptom (napr. cyklicky sa snaží pripojiť na postgresql kým sa mu to nepodarí alebo kým neskončí timeoutom), ale systemd, ktorý spúšťa hneď ako je dependency splnená by s tým mal v niektorých prípadoch problém. Napr. mám službu, ktorá potrebuje pri štarte bežiaci postgres - bez toho aby init vedel kedy je postgres skutočne pripravený by takáto služba nebola shocpná naštartovať.

[Filip Jirsák]

A podle někoho zase webový server běží, pokud na portu 443 odpovídá očekávanou stránkou. Pokud odpovídá 500, tak je jedno, že naslouchá na portu.

Správce služeb ale řeší procesy, systemd navíc umí přes sd_notify získat informaci, že proces je opravdu připraven přijímat požadavky (pokud to proces podporuje), případně umí procesu předat už aktivovaný naslouchající socket (takže klienti už mohou navazovat spojení, zatímco služba ve skutečnosti teprve startuje). Jestli služba běží správně, to už si musíte kontrolovat nějakým monitoringem, protože je to u každé služby jiné a byl by nesmysl něco takového tahat do správce služeb.

[joejoe]

Sysvinit umoznuje naspat cokoliv, a to prave i tu kontrolu jestli web server vraci 200. Dava mi vetsi smysl do systemd pridat monitoring sluzeb nez jine veci (treba systemd-resolvd).

O sd_notify jsem si precetl az tady. Diky (-; Problem je, ze to proces musi podporovat. Navic bude slozite to napsat tak, aby to skutecne vyresilo jestli je sluzba ziva nebo mrtva..

[Filip Jirsák]

Sysvinit umoznuje naspat cokoliv, a to prave i tu kontrolu jestli web server vraci 200.

Ne, to SysVinit neumožňuje. Umožňují to shell skripty, kterými je SysVinit obvykle obalen. Ale k čemu vám bude dobrý shell skript, který jednou za uherský rok, když správce spustí ručně /etc/init.d/httpd status, zkontroluje, zda webový server vrací kód 200, to je mi záhadou. Na stav služby chci reagovat hend, když se změní.

Navic bude slozite to napsat tak, aby to skutecne vyresilo jestli je sluzba ziva nebo mrtva..

Ono to taky není určeno k tomu, aby to monitorovalo kvalitu služby. Typické použití je, že služba se spoustí, načte konfiguráky, zkontroluje je, nakonfiguruje se podle nich, načte třeba potřebné datové soubory, a pak začne naslouchat na portu a je připravena zpracovávat požadavky. A ten okamžik začátku naslouchání na portu je právě okamžik, kdy je z pohledu správce služeb služba připravena a mohou začít startovat služby, které na ní závisejí.

[mirec]

Vie zistiť, či proces beží a ak je služba napísaná a skompilovaná s podporou sd_notify tak dokonca vie, či aj reálne naštartovala. V bežných init skriptoch sa to budď nerieši (skript nezaujíma, či služba už reálne dokáže odpovedať na požiadavky), alebo sa to rieši pevným timeoutom, alebo sa to rieši pollingom.

[Heron]

Nebo jenom zjistuje ze je spusteny nejaky z procesu v cgroup?

No systemd dokonce nezjišťuje ani to. Systemd je jedno, zda mu z cgrupy zmizí všechny procesy, prostě považuje službu dál za spuštěnou.

Hlavně, že má potřebu celou cgrupu killnout při ukončení služby.

Ale to je jedno, tyhle diskuse nemají smysl. Nikdy není chyba na straně systemd, vždy je chyba na naší straně a už dokonce nemáme používat ani distribuční unity, ale všechno si psát sami .

[Jendа]

Dnešní noční zážitek se systemd na Debianu. Určitě je to způsobené špatně napsanými unit files a ne systemd.

Upgradnul jsem server na stretche, reboot, a nic. Po nějaké době připojím konzoli a vidím

A start job is running for Create Volatile Files and Directories [11 minutes and counting / no limit]

Googlení radí přesunout /usr/lib/tmpfiles.d/ a zkusit nabootovat bez toho. To dělám, systém bootuje, ale nenajíždí sshd, protože neexistuje /run/sshd.

Long story short, před upgradem jsem do /tmp vydumpoval kvůli záloze metadata z Artifactory, což je velké množství malých souborů. Promazání /tmp kvůli tomu trvalo „příliš dlouho“ a někde něco vytimeoutovalo. Ruční smazání /tmp/* a systém najel.

Fascinující.

[dustin]

Jo to "XXX minutes and counting/no limit" miluju.

[Jendа]

Já naprosto nechápu, proč tam neudělali možnost třeba zmáčknutím Ctrl+C unitu na kterou se čeká odstřelit (jako to mají distribuce bez systemd, podle nastavení buď rovnou hodí rootshell, nebo se zeptají na root heslo). Sice pak něco nenajede (v tomto případě sshd), ale většinou by ses alespoň dokázal přihlásit (na konzoli) a opravit to. Takhle člověk musí lézt do FS toho virtuálu z hypervizoru nebo pokud je to fyzický stroj řešit jak nabootovat z Live CD/USB.

[michich]

Systemd je jedno, zda mu z cgrupy zmizí všechny procesy, prostě považuje službu dál za spuštěnou.

To je správné chování pro služby s RemainAfterExit=yes.

[Dikobraz Fik]

Systemd je zhovadilost ... hodna Powershellu

[Pavel 'TIGER' Růžička]

PowerShell docela slušně rozšiřuje možnosti Windows, to u systemd nevidím. Systemd je opětovné vynalézání kola, stejně jako opakované přepisování desktopů. Přitom desktop má jen spouštět aplikace, nic víc. A zrovna aplikací je stále nedostatek.

[M.]

Jen pro info. Jako dlouhodobý hater systemd a podobných výplodů (např. PulseAudio) jsem byl na Debian Sid nucen přejít na systemd init a musím obejktivně přiznat, že většina problémů, které s tím jsou jdou na vrub chybně napsaným unit skriptům a gulášem se skripty v init.d. Tam je skutečně nutné (pokud chceme mít alespoň šanci, že to bude správně reagovat), aby se serverové služby spouštěli na popředí, obdobně jako v runit, což je ve spoustě případů ignorováno. Hledat pak v tom, proč zrovna něco nejede je celkem výzva. Podle mě si to musí v těch distribucích sednout, což bude asi ještě pár let trvat. Já osobně tedy vždy preferoval runit, ale dokud mě systemd nevypeče nějak významně při bootu, tak mu dám na stanici šanci.