Portál AbcLinuxu, 10. května 2025 05:00
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.
Tiskni
Sdílej:
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ší.
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ť.
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í.
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.
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
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í.
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
.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.