Dotaz: Fedora 17, systemd a SysV init skripty

[Radek Hladik]

Zdravím,

chtěl bych se zeptat, zda je možné v systemd ve Fedoře 17 zařadit SysV init skript jako wants. V principu mi jde o to, že mám vlastní firewallovací init skript a chtěl bych ho zařadit před start služeb. Tedy aby patřičný "checkpoint" (nebo jak se to nazývá) počkal, až se spustí. Jako vhodný se mi zdá sysinit.target.wants, ale jestli to správně chápu, tak do toho adresáře v /etc/systemd/... můžu linkovat jen unity. Pokud by to nešlo, tak to se skřípěním zůbů přepíšu na unit file, ale radší se nejdřív zeptám

P.S. Dájí se nějak ty [Ok] při startu přehodit doprava, jako to bylo ve F16?

P.P.S. Opravdu bych nechtěl (opět) rozpoutat nějaký flamewar, takže poprosím pouze technické odpovědi :)

---

---

Odpovědi

[pavlix]

chtěl bych se zeptat, zda je možné v systemd ve Fedoře 17 zařadit SysV init skript jako wants. V principu mi jde o to, že mám vlastní firewallovací init skript a chtěl bych ho zařadit před start služeb.

Chybyčka. Ani wants ani requires v systemd neslouží k ovlivnění pořadí startu služeb, ale k vyjádření toho, která služba kterou chce/potřebuje. To, co hledáš je after/before, popřípadě kombinace obojího (tedy určení závislosti i pořadí).

P.S. Dájí se nějak ty [Ok] při startu přehodit doprava, jako to bylo ve F16?

Netuším. Mně funguje grafický start, takže tyhle věci vidím jenom když chci a pak zas neřeším estetiku.

P.P.S. Opravdu bych nechtěl (opět) rozpoutat nějaký flamewar, takže poprosím pouze technické odpovědi :)

To je zbytečné. Flamewar buď přijde nebo nepřijde, tazatel ho může pouze vyprovokovat, ne mu zabránit :).

[Radek Hladik]

Chybyčka. Ani wants ani requires v systemd neslouží k ovlivnění pořadí startu služeb, ale k vyjádření toho, která služba kterou chce/potřebuje. To, co hledáš je after/before, popřípadě kombinace obojího (tedy určení závislosti i pořadí).

Tomu rozumím, ale měl jsem pocit, že jsou tam určitá místa, jakýsi checkpointy, kde se počká na všecko, co do té doby mělo být, ale možná se mýlim. Jako aby každá služba nemusela mít jako závislost mount, storage-init, atd...

[pavlix]

O checkpointech přesně nevím, to bude vědět michich jestli tam něco takového je. Jen šlo o to, že wants/requires určuje závislosti typu služba X potřebuje službu Y, přičem nedefinuje, zda ji potřebuje před svým startem nebo po něm.

[Radek Hladik]

Pardon, trochu jsem to popletl. Nejmenuje se to checkpoint, ale je to target, ale takový ten, kterým se projde při bootu, ale není ještě finální - sysinit,sockets,network,atd... Měl jsem v těch pojmech trochu zmatek, myslel jsem, že target je jen ten jeden cílový (třeba multiuser).

Ale každopádně myšlenka je stejná a je to na tom bootu i vidět. Nemá smysl, aby třeba mysql mělo závislost na třeba remount-root-fs, takže se udělá nějaký bod (sysinit, network), který shrne určitou část bootu a mysql se pak už odkazuje na něj. Při bootu je vidět, že se na takovém místě boot zastaví, dodělají se služby, které musí a pak to pokračuje.

[pavlix]

Jo, máš pravdu. Akorát je potřeba si pamatovat, že pořadí a závislosti jsou ortogonální a bude to fungovat.

[Radek Hladik]

Se SysV skriptem se před sysinit.target nedostaneš.

Ten unit file by vypadal nějak takto - /etc/systemd/system/mujfw.service:

[Unit]
Description=firewall skript, co se spouští hodně brzo
DefaultDependencies=no
After=local-fs.target
Before=sysinit.target
# Conflicts= a Before=shutdown.target u tohoto unitu asi nejsou nutné
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/etc/rc.d/init.d/mujfw start
ExecStop=/etc/rc.d/init.d/mujfw stop
[Install]
WantedBy=sysinit.target

Pozice těch vypisovaných "[ OK ]" značek je zakódovaná natvrdo. Doleva jsem to přesunul schválně, protože na širokých monitorech už nešlo pouhýma očima poznat, ke kterému řádku která značka patří.

[Radek Hladik]

Díky, zkusím.

Jestli tomu dobře rozumím, tak pokud init skript nemá unit file, tak se spouští až někdy ke konci hromadně, zatímco, když má unit file, tak se spustí, kdy chci? Takže to, že používám službu network místo NetworkManageru, znamená, že se mi síť spouští až skoro nakonec (jestli jsem se nepřehlíd, tak unit file nemá)?

A nešla by pozice těch Ok nastavovat v konfiguraci, je to drobnost, ale přeci jen jsem za těch snad už 20 verzí Fedory a Redhatu zvyklý

[covex]

Ach ta vecna konfigurovatelnost. Presne z toho duvodu je konfigurace systemd takovy binec. Puvodni myslenka hezka, ale reseni startu chronyd vs. ntp vyzaduje vymyslet dalsi parametr. Me se to vlevo libi vic.:)

Jinak nevim co myslis rozdilem init scriptu a unit - unit je jen obecny popis pro konfiguraci, ktera muze poustet co chce, treba init script, jako to napsal michich.

[Radek Hladik]

Jinak nevim co myslis rozdilem init scriptu a unit - unit je jen obecny popis pro konfiguraci, ktera muze poustet co chce, treba init script, jako to napsal michich.

To vím, ale tady jsem četl, že systemd volá init skripty, pokud nenajde unit file stejného jména. Z toho a z toho, co psal michich, jsem usoudil, že když pro init skript udělám unit file, který se bude stejně jmenovat (a bude volat ten init skript), tak ho de facto vyřadím z "defaultního zpracování všech plebejských init skriptů" a budu si ho moct řídit kompletně pomocí systemd.

[michich]

SysV skripty a nativní unity, které se tomu nebrání přes DefaultDependencies=no, se spouštějí až po basic.target. Tady jsou nejdůležitější targety při bootu: http://0pointer.de/public/systemd-man/bootup.html

Pořadní závislosti unitu si můžeš vypsat systemctl show -p Before -p After foo.service

Přidávat volbu pro pozici výpisu OK se mi moc nechce.

[Radek Hladik]

Příloha:

• 0439-unit-print-the-color-status-marks-back-on-the-right.patch (3737 bytů)

Díky, už to pěkně chodí, služby se spouštějí, kdy mají. Teď už jen zjistit, proč si stežuje, že "Dependency failed for Network Manager Wait Online", když má vypnutý NetworkManager. Ale k tomu se asi ještě dočtu

S tím OK to není potřeba nějak hrotit, drze jsem si udělal patch (v příloze), který revertne tvůj patch na přesun doleva (oproti systemd-44-17.fc17.srpm)

[pavlix]

To znamená, že to má nějaká služba jako závislost. Čistě mezi náma, nm-online je ošklivý hack, protože správně by měla služba umět reagovat na změny síťové konfigurace (tedy pokud to není primitivní služba na wildcard adrese, což většinou stačí).

Některé služby nejsou schopné se přizpůsobit aktuální situaci ani přes netlink, ani přes NM, takže při startu čekají na nm-online (tedy myslím až 30 sekund timeout, pokud nenajede síť) a ještě do /etc/NetworkManager/dispatcher.d přidávají hook, který je restartuje. Pokud NM vůbec neplánuješ používat, není problém závislost na nm-online úplně odstranit.

[Radek Hladik]

Je to server, v tomhle případě dokonce "jednoslužbový". Na desktopu s NM problém nemám, ale na serveru preferuju jednoduchost staré dobré network. Navíc síť nahazuje už dracut (dokonce jako bridge), takže tady potřebuju jenom přiházet další adresy a nastavit routy, úplně krásně by stačil skriptík, co 3x zavolá ip něco něco.... Navíc to nesmí tu síť ani na chvíli shodit, dokonce mám hned na začátku stop části v tom network initscriptu exit, protože Fedora pořád nedokáže správně poznat, že síť nemá shazovat... Do toho si opravdu nemám chuť pustit poměrně nepredikovatelný NM

Takže jsem udělal systemctl disable NetworkManager.service a on se opravdu nespustí. Ale je tam nem nm-online, který ovšem nenám nikde v /etc/systemd nalinkovaný a ani jsem tam nenašel žádný soubor, který by obsahoval "online". Na druhou stranu, pokud to opravdu jen napíše warning, že nm-online pláče po nm, tak se nic neděje...

[Radek Hladik]

Tak mně napadá, jak je v systemd vyřešeno to, že služba může mít různé závislosti podle toho, jaká je na serveru konfigurace? Konkrétně například to, co jsem nastínil výše. Řekněme, že nechám NM jakožto moderní věc, která se mi má starat o síť. Dejme tomu, že boot nějak projde a já chci stroj vypnout. Dejme tomu, že Fedoří skripty správně vyhodnotí _rnetdev u / ve fstab nebo že si všimnou, že root je na md raidu, kde jedinné aktivní membery jsou iSCSI. V takovou chvíli je ovšem tedy potřeba, aby NM shodil síť až úplně na konci nebo jí klidně i nechal, to nikoho nezabije. Samozřejmě můžu závislositi ručně změnit, ale to není moc ideální. Například starý network skript v části stop udělá nějakou detekci a pokud to vyhodnotí, jako že nemá shazovat síť, tak neshazuje (jen v mém případě trochu hapruje ta detekce).

Jestli jsem dobře koukal, tak systemd vůbec iSCSI neřeší, na všecko volá původní init skripty iscsid a iscsi, což je řešení alespoň částečně funkční, ale rozhodně bych si představoval, že takovouto věc bude systemd nějak řešit. Už jen to, že se takovýto iscsi initscipt spustí po většině služeb, není moc ideálni A to, že při shutdown zavolá iscsi stop mezi jedněmi z prvních, je už naprostá katastrofa, protože to je poslední, co udělá, pokud má na iSCSI root...

[pavlix]

Tak mně napadá, jak je v systemd vyřešeno to, že služba může mít různé závislosti podle toho, jaká je na serveru konfigurace?

Jako že by byla různá struktura závislostí pro různé profily? To si nemyslím.

V takovou chvíli je ovšem tedy potřeba, aby NM shodil síť až úplně na konci nebo jí klidně i nechal, to nikoho nezabije.

Ukončení NM obecně neshazuje síť. Dřív to tak nebylo, a některé chybi i vlastnosti (kvůli problémům kernelu) shození sítě způsobují. Ale oficiální plán je ten, že ukončení NM nechá síť viset tak jak je pro případ, že se jedná o upgrade a NM se bude zase spouštět a konfiguraci si bude přebírat.

Momentálně to funguje jen pro IPv4 a i tam jsem opravoval před 0.9.6 nějakou chybu (kód pro IPv6 jsem odstraňoval úplně, protože nefungoval, jen dělal problémy).

A to, že při shutdown zavolá iscsi stop mezi jedněmi z prvních, je už naprostá katastrofa, protože to je poslední, co udělá, pokud má na iSCSI root...

Já bych to asi hlásil do bugzilly. Do redhatí, abych nemusel moc řešit jestli je to problém systemd nebo unity té služby, oni už si to nějak přehodí.

[pavlix]

úplně krásně by stačil skriptík, co 3x zavolá ip něco něco...

To je kolikrát nejlepší.

protože Fedora pořád nedokáže správně poznat, že síť nemá shazovat...

To by mě docela zajímalo, za jakých okolností Fedora shazuje síť bez žádosti uživatele.

Do toho si opravdu nemám chuť pustit poměrně nepredikovatelný NM

Chápu :).

ani jsem tam nenašel žádný soubor, který by obsahoval "online"

$ find /lib/systemd/ | grep online
/lib/systemd/system/NetworkManager-wait-online.service
/lib/systemd/system/remote-fs-pre.target.wants/NetworkManager-wait-online.service

Na druhou stranu, pokud to opravdu jen napíše warning, že nm-online pláče po nm, tak se nic neděje...

Na ten warning se akorát bude nejspíš čekat půlminutový timeout.

[Radek Hladik]

Odpovědi na obojí do jednoho příspěvku:

protože Fedora pořád nedokáže správně poznat, že síť nemá shazovat...

To by mě docela zajímalo, za jakých okolností Fedora shazuje síť bez žádosti uživatele.

A to, že při shutdown zavolá iscsi stop mezi jedněmi z prvních, je už naprostá katastrofa, protože to je poslední, co udělá, pokud má na iSCSI root...

Já bych to asi hlásil do bugzilly. Do redhatí, abych nemusel moc řešit jestli je to problém systemd nebo unity té služby, oni už si to nějak přehodí.

Ono to spolu souvisí. Pokud je root na iSCSI nebo něčem, co potřebuje síť, tak by shození sítě nemělo k tomu potřebné věci shodit. Postupně s tím bojuju už od cca Fedory 8, psal jsem to do bugzily (ikdyž už nemůžu ty bugy najít), ale nějak tak od cca fedory 12-13 s tím nebyl problém.

Problém je v tom, že cca ve fedoře 7 mělo mkinitrd sice detekci, zda root nepotřebuje iSCSI, ale nebylo to rekurzivní. Takže pokud boot byl přímo na iSCSI, tak ok, ale pokud byl na raidu, kde bylo iSCSI, tak už ne. Ale to šlo jen dělání ramdisku, takže člověk holt musel po každém upgradu kernelu přegenerovat ramdisk s parametry, aby se zahrnulo iSCSI. Už zhruba někdy od té 7-8 to dělalo to, že ve cvhíli, kdy se rozjelo iscsi, tak to vyplo shození síťovek při network stop. A ta detekce se dala obejít přidáním _netdev nebo _rnetdev do fstabu. Pak přišel dracut, který v tom nadělal vcelku pořádek a pokud se přegeneruje ramdisk, aby měl iSCSI a síť, tak je to všecko otázka parametrů kernelu a pak jen je potřeba, aby tu síť nikdo neshodil. Původní rc sckript netowkr to už měl docela vymakané, ale teď je jak iscsi tak network spouštěnej jen přes "kompatibiltu s InitV", takže se spouští jako poslední, resp. první. Nevím, jestli to hlásit do bugzily, zda je network ještě pořád podporovaný nebo ne, stejně tak nevím, zda pro iscsi neexistuje nějaká novější varianta...

To bylo celé, co jsem měl na mysli, tedy to, že fedora neshazuje síť bez přání uživatele, ale při shutdownu to shazuje v jiném pořadí, než jak by bylo podle aktuální konfigurace potřeba.

Tak mně napadá, jak je v systemd vyřešeno to, že služba může mít různé závislosti podle toho, jaká je na serveru konfigurace?

Jako že by byla různá struktura závislostí pro různé profily? To si nemyslím.

No myslím to tak, že by se struktura závislostí měnila podle nějakých parametrů. Řekněme, že nastavím, aby se server autentizoval proti winbindu, pak je například rozumné (ikdyž ne nutné) mít závislost: sshd potřebuje winbind. Prostě a jednoduše to, že se závislostí mění podle aktuálního nastevení nečeho jiného na serveru. Ten remote root je taky dobrý příklad. Prostě pokud mám root připojený přes síť, tak najednou síť potřebuju shazovat mezi posledními. To že to ve skutečnosti síť neshodí je jen taková obezlička, sice funkční, ale ne moc čistá, třeba řekněme, že budu mít root nejen přes síť, ale přes IPSec. Pak mi nestačí, že síť zustane nahozená, kdyby nezůstal nahozený IKE. Což je další přiklad toho, že se IKE může shazovat jako jeden z prvních nebo naopak skooro až na konci, podle potřeby... Jako admin si to můžu nastavit, ale přijde mi, že to je věc, kterou by se systemd snaží řešit, tak mně zajímá, jak a jestli....

$ find /lib/systemd/ | grep online

Proto jsem psal, že jsem to nenašel v /etc/systemd, tedy že to není ani moje lokální unit, ani v nějakém wants nebo jako přímá závislost. Čímž pádem nemám přímočarý prostředek, jak to vypnout... Ale ani to pul minuty netimeoutuje, jen to napíše, dependency failed a jede dál....

[petr_p]

Jako admin si to můžu nastavit, ale přijde mi, že to je věc, kterou by se systemd snaží řešit, tak mně zajímá, jak a jestli...

Obávám se, že takové magie nebude žádný init schopný. Když už správce nastaví ipsecovou politiku pro iSCSI, tak náležitě upraví závislosti mezi službami.

V případě systemd lze v /etc/systemd/system vytvořit stejnojmenný jednotkový soubor, do něj napsat direktivu pro vložení obsahu původní jednotky z /usr/lib/systemd/system a přidat specifikaci kýžené závislosti.

[Radek Hladik]

Tak určitě záleží na míře. Například klasický init (nebo možná spíš už runinit, upstart nebo co, ale to není podstatné) ve Fedoře okolo verze 11-13 poměrně elegatně výše nastíněný problém s (ne)shazováním sítě a iSCSI zvládal. Nebylo to kdovíjak elegatní, správce od iscsid musel šahat do skriptu od sítě, do mkinitrd a buhví kam všude jinam, ale fungovalo to. Ten IPSec jsem myslel spíš jako extrémní příklad... Ruční úprava mi problém nedělá, ale zajímalo mně, jestli má systemd vůbec nějaký mechanismus, jak může unit file dynamicky řešit svoje závislosti...

[petr_p]

Obávám se, že to je základní vlastnost systemd – jednotkové soubory nejsou skripty.

[Radek Hladik]

To ale ještě neznamená, že nemůžou mít nějakou schopnost komplikovanější parametrizace. A navíc to, že to nejsou skripty je tak trochu marketing, protože pořád ještě hodně věcí dělají přes volání skriptů nebo se tomu vyhýbají. Například to s tím postgresql initdb (jak jsem psal tady). To je typická práce pro nějaký skript...

Stejně jako to, že by unit file mohl zavolat skript nebo třeba nějaký svůj modul, který by zjistil, zda je používané iSCSI, a pak by správce iscsid do unit filu networku přidal něco jako: dependency=(isiscsi.sh)?iscsi:nic...

[pavlix]

Já jsem docela rád, že tam takováhle černá magie není.

[Radek Hladik]

No někdo to považuje za černou magii, někdo za běžnou věc . Když si vezmu, že celý systemd se snaží de facto o přechod od imperativniho paradigma k deklarativnímu...

[pavlix]

Což o to, pro mě je černá magie běžná věc :). Provozuju ji hlavně na sítích, ale pokud něco vytvářím, snažím se chovat tak, abych k jejímu použití nenutil druhé.

[Radek Hladik]

Kdo říká nutil, pokud tam ta možnost je, tak je na uživateli (ve smyslu systemd spíš tvůrci unit než koncovém uživateli), zda jí použije. Pokud tam není, tak jí nepoužije a pak to musí řešit různými ošklivými hacky....

[pavlix]

To bylo celé, co jsem měl na mysli, tedy to, že fedora neshazuje síť bez přání uživatele, ale při shutdownu to shazuje v jiném pořadí, než jak by bylo podle aktuální konfigurace potřeba.

Jo, já to všechno celkem chápu. Jen by mě zajímaly přesné okolnosti které vedou k tomu, že Fedora shodí síť a taky jestli to má nebo nemá souvislost s NetworkManagerem. Mám pocit, že by měl být tenhle problém vcelku jednoduše řešitelný.

Řekněme, že nastavím, aby se server autentizoval proti winbindu, pak je například rozumné (ikdyž ne nutné) mít závislost: sshd potřebuje winbind.

Ty závislosti se někdy značně přeceňují.

Prostě pokud mám root připojený přes síť, tak najednou síť potřebuju shazovat mezi posledními.

To je takové dost nekonkrétní.

Pak mi nestačí, že síť zustane nahozená, kdyby nezůstal nahozený IKE.

Čistě teoreticky může IKE použít stejný trik. Může se shodit aniž by došlo k okamžitému shození IPsec.

ale přijde mi, že to je věc, kterou by se systemd snaží řešit, tak mně zajímá, jak a jestli....

Jak jsem psal výše, nemám pocit, že by se snažil toto řešit. Jediné, o co se snaží je se tomu vyhnout a přesunout část zodpovědnosti za závislosti na aplikace.

Čímž pádem nemám přímočarý prostředek, jak to vypnout...

Můžeme se přít o tom, jestli je to dobře nebo špatně. Ale je to zdokumentované, alespoň :).

Ale ani to pul minuty netimeoutuje, jen to napíše, dependency failed a jede dál....

Tak ono to vlastně bude timeoutovat jen pokud bude NM spuštěný ale nebude se mu dařit získat spojení.

[Radek Hladik]

Ty závislosti se někdy značně přeceňují.

No jestli to správně chápu, tak je to jediná možnost, jak nastavit, že nějaká unit potřebuju nějakou jinou unit...

Prostě pokud mám root připojený přes síť, tak najednou síť potřebuju shazovat mezi posledními.

To je takové dost nekonkrétní.

Nevím, co je na tom nekonkrétní, ale budž, zkusím trochu vyelaborovat. Ve chvíli, kdy soubory potřebné pro běh systemd a dalších služeb jsou na partition, která je připojená přes NFS, SMB,... nebo na disku, který je připojený přes iSCSI nebo obsahuje (LVM, Device Mapper, mdraid, dmraid) disk, který je připojený přes iSCSI, tak je potřeba neshazovat síťovku, přes kterou se takto komunikuje, dokud nejsou tyto partitions odmountovány. Protože je to poměrně složitý oříšek, tak se používaly zjednodušení typu neshazuje se žádná síť, aby se nemuselo řešit, kterou síťovku můžu a kterou ne, admin do fstabu připíše "hint", že ten filesystém je _netdev nebo _rnetdev...

Čistě teoreticky může IKE použít stejný trik. Může se shodit aniž by došlo k okamžitému shození IPsec.

To jo, ale tenhle přístup je principielně špatný. Pokud byl démon potřeba za provozu, měl by být potřeba celou dobu, co se ta věc používá. Není dobré spoléhat na to, že ten shutdown bude trvat krátce, to vnáši nějaké implicitní omezení, které nemusí být pravda...

Jak jsem psal výše, nemám pocit, že by se snažil toto řešit. Jediné, o co se snaží je se tomu vyhnout a přesunout část zodpovědnosti za závislosti na aplikace.

No ale to je docela divné ne? Ta aplikace nemá přece řešit komplexitu těch závislostí, přece nebudeš do NM programovat detekci, zda root potřebuje síť, zda jí potřebuje /usr (tedy detekovat, jestli je nebo není /usr na jiné partition) (to se samozřejmě dá po lenartovsku odbýt, že to je crazy věc)? Když ideální řešení by právě bylo mít na tuto poměrně složitou detekci vlastní unit file, který by sloužil ostantím jako zdroj informace a oni (klidně na úorvni aplikace) by se podle něj zařídili....

Můžeme se přít o tom, jestli je to dobře nebo špatně. Ale je to zdokumentované, alespoň :).

Já se (kupodivu) nepřu, v tomhle případě je mi to poměrně šumák, ale zarazilo mně, že se spustí něco, na co nemám v /etc/systemd nějakou jasnou vazbu. Ale asi má systemd nějakou volbu, která vypíše, co všechno se při startu bude volat (jako bylo ls /etc/rc.5....)

[pavlix]

No jestli to správně chápu, tak je to jediná možnost, jak nastavit, že nějaká unit potřebuju nějakou jinou unit...

Ano. A přesně to je značně přeceňováno, zvláště pokud se jedná o závislosti, které mají vliv na pořadí spouštění. V jazyce systemd tedy before/after.

tak je potřeba neshazovat síťovku, přes kterou se takto komunikuje

Mně přijde ideální neshazovat síťovku vůbec. A zřejmě je to cesta, kterou se budeme opravdu ubírat. Původně jsem s tím nesouhlasil, ale kluci mě přesvědčili, že to dává smysl. Akorát zatím tento postup aplikujeme myslím pouze na Ethernet.

Není dobré spoléhat na to, že ten shutdown bude trvat krátce, to vnáši nějaké implicitní omezení, které nemusí být pravda...

Kdybych cítil naději, že se celá věc vyřeší ideálním způsobem, tak s tebou možná budu souhlasit.

No ale to je docela divné ne?

Podle mě není. Aplikace ty závislosti stejně vidí/řeší. Navíc jedině aplikace zná své skutečné závislosti, pokud jsou odvozené od konfigurace.

přece nebudeš do NM programovat detekci, zda root potřebuje síť, zda jí potřebuje /usr

To rozhodně nebudu. Závislosti se vždy řeší na straně, která závisí, ne na straně, na které se závisí.

V NetworkManageru máme všechny běhové závislosti řešené opravdu za běhu. Navíc NetworkManager samozřejmě používá /etc, takže pokud by se měl NetworkManager používat k získání kořenového adresáře, tak jsou závislosti mezi ním a kořenem stejné jako závislosti mezi initem a kořenem.

Řešit to lze jedině tak, že bude NetworkManager (ořezaný na minimum odstraněním všech nepotřebných modulů) stejně jako init zabalený do initrd. Při ukončení může NetworkManager nechat nakonfigurovanou síť (na Ethernetu to částečně funguje) a po mountování se spustí nový init, který spustí nový NetworkManager, který si síťovou konfiguraci převezme.

Samozřejmě z toho vyplyne řada problémů a omezení, ale v tuhle chvíli to nejde rozumně řešit jinak.

Když ideální řešení by právě bylo mít na tuto poměrně složitou detekci vlastní unit file, který by sloužil ostantím jako zdroj informace a oni (klidně na úorvni aplikace) by se podle něj zařídili....

Takhle to na Linuxu nefunguje. Alespoň ne v tuto chvíli.

Já se (kupodivu) nepřu, v tomhle případě je mi to poměrně šumák, ale zarazilo mně, že se spustí něco, na co nemám v /etc/systemd nějakou jasnou vazbu.

ale zarazilo mně, že se spustí něco, na co nemám v /etc/systemd nějakou jasnou vazbu.

Přitom si stačilo přečíst manuál.

Odložení distribučních konfiguráků do /usr/lib umožňuje zcela obejít problém s updatem konfiguračních souborů, kdy není bez zásahu uživatele zcela rozhodnutelné, zda chce uživatel konfigurační soubory přepsat či nikoli. V /etc se pak nacházejí jen uživatelské úpravy.

Má to svoje výhody především v případě konfiguračních adresářů, jejichž konfigurace se může často měnit balíčkovacím systémem a konflikty s uživatelskou konfigurací jsou rozlezlé přes hromadu souborů. V případě problémů pak administrátor jenom smaže celý uživatelský override a udělá si případně lokální úpravy znovu.

[Radek Hladik]

Ano. A přesně to je značně přeceňováno, zvláště pokud se jedná o závislosti, které mají vliv na pořadí spouštění. V jazyce systemd tedy before/after.

Tomu nerozumím, co je značně přeceňováno. To že nějaká služba potřebuje jinou?

přece nebudeš do NM programovat detekci, zda root potřebuje síť, zda jí potřebuje /usr?

To rozhodně nebudu. Závislosti se vždy řeší na straně, která závisí, ne na straně, na které se závisí.

No jasně, tak budou muset lidi od iscsid dodělávat do svých věcí toto, kam to vcelku logicky patří. Ale NM jim pak stejně bude muset nabídnout nějakou možnost, jak se nechat řídit tak, aby šlo udělat to, co oni potřebují. A proto mi připadá init proces ideální mezinástroj, který v tom může napomoci...

Přitom si stačilo přečíst manuál.

Přitom si stačilo přečíst mé příspěvky. Já princip oddělení lokálních a systémových souborů chápu. Ale šlo mi o to, že se míchají věci z /usr s věcmi z /etc takovým způsobem, že není jednoduché zjistit, co všechno se tedy použije... Dokonce jsem si ze začátku myslel, že v /etc budu mít přesně to, co se lokálně má použít a věci z /usr se budou používat jen jako nástroje pro to, ale to jsem brzy zjistil, že to tak není. Každopádně jsem tohle shrnul v příspěvku níže, protože jsem se toho chvíli snažil zbavit.

Není dobré spoléhat na to, že ten shutdown bude trvat krátce, to vnáši nějaké implicitní omezení, které nemusí být pravda...

Kdybych cítil naději, že se celá věc vyřeší ideálním způsobem, tak s tebou možná budu souhlasit.

To je zajímavý přístup, podmiňovat (ne)souhlas s koncepční myšlenkou nějakým subjektivním pocitem z něčeho souvisejícího. Ale proč jsem o tom psal bylo, že například libvirt-guest si v klidu při shutdownu začal ukládat snapshoty běžících strojů. Nic divného a nevidím důvod, proč by to bylo špatně, ale celý shutdown pak trval třeba 10 minut....

[pavlix]

Tomu nerozumím, co je značně přeceňováno. To že nějaká služba potřebuje jinou?

Ano. A především to, že je potřeba to pořád nějak komplikovaně řešit.

Ale NM jim pak stejně bude muset nabídnout nějakou možnost, jak se nechat řídit tak, aby šlo udělat to, co oni potřebují.

NM jim může maximálně tak nabídnout garanci, že nezasáhne té části konfigurace sítě, kterou používají. A to není až tak složité, pro začátek stačí požadavky popsat v bugzille.

A proto mi připadá init proces ideální mezinástroj, který v tom může napomoci...

Nemyslím si, že existuje vůbec nějaký způsob, jak v tomto může init pomoci, tedy pokud init sám nebude síťovým démonem. Není to ani v nejmenším jeho věc.

Ale šlo mi o to, že se míchají věci z /usr s věcmi z /etc takovým způsobem, že není jednoduché zjistit, co všechno se tedy použije...

Podle mě je to velice jednoduché. Uživatelské konfigurační soubory (v /etc) mají přednost před stejnojmennými distribučními konfiguračními soubory (v /usr/lib). To je všechno.

To je zajímavý přístup, podmiňovat (ne)souhlas s koncepční myšlenkou nějakým subjektivním pocitem z něčeho souvisejícího.

A ještě navíc možná :). Suchá teorie a praxe se prostě občas liší. Ale když nad tím tak přemýšlím, tak v podstatě to, co bys chtěl, už systemd umí. Ty bys totiž chtěl několik grafů závislostí. Vtip je v tom, že se všechny klidně vejdou do jednoho.

Ale proč jsem o tom psal bylo, že například libvirt-guest si v klidu při shutdownu začal ukládat snapshoty běžících strojů.

Jo, taky mě nějaké náročnější akce napadly. Takže jsi mě přesvědčil, u těch síťových věcí, které je potřeba udržovat.

Takže jo. Bylo by fajn mít vyřešené závislisti mezí sítí a síťovým filesystémem. Takže odpojit síťový root, než se ukončí třeba ten strongswan. To asi nepůjde. Možná je samotný root po síti špatný nápad a měl by být radši v RAM.

Takže jediné, co mě napadá, je oddělit klíčové komponenty a aplikace. Tedy odložit ukončení síťových démonů až po ukončení toho virtualizačního software. Ony ty virtuály síť stejně nejspíš potřebují :).

A tohle systemd podle mě zvládne.

[Radek Hladik]

Jo, taky mě nějaké náročnější akce napadly. Takže jsi mě přesvědčil, u těch síťových věcí, které je potřeba udržovat.

Takže jo. Bylo by fajn mít vyřešené závislisti mezí sítí a síťovým filesystémem. Takže odpojit síťový root, než se ukončí třeba ten strongswan. To asi nepůjde. Možná je samotný root po síti špatný nápad a měl by být radši v RAM.

Já zase můžu vyjmenovat spoustu důvodů, proč je síťový root dobrý nápad. Dva příklady za všecky. Máme servery, které bootuji z flashky, ze které si stáhnou kernel a initrd, vše ostatní je na iSCSI. Takovou flashku můžu naprosto triviálně vrazit do jiného HW a jedu dál. Ideální právě pro virtuální hostitele. Dřív byl problém s rozdílným HW, ale to velice elegatně vyřešil dracut. Druhým příkladem jsou různé servery, které mají klidně i lokální raid a na iSCSI mají další member. A nějaké drobné nenáročné servery mají třeba jen jeden lokální a jeden síťový. A v nejhorším je možné ten server dočasně (ale rychle) pustit z toho iSCSI, takže třeba pod virtualizací. Tady by se dalo namítnout, že když se odpojí síť, tak to pojede z toho lokálního, ale to se doufám shodneme, že je špatné řešení

Takže jediné, co mě napadá, je oddělit klíčové komponenty a aplikace. Tedy odložit ukončení síťových démonů až po ukončení toho virtualizačního software. Ony ty virtuály síť stejně nejspíš potřebují :).

Ty virtuály tu síť už potřebovat nemusí, navíc na ní nemusí být závislé... Přiznám se, že nevím, jestli je ten init skript nejdřív všechny pauznul a pak po jednom snapshotoval, nebo to dělal postupně. Já to tak i tak nepovažuju za moc ideální řešení, takže pokud se vypíná hostitel, vypnu i všechny stroje, stejně se většinou jedná o síťové servery, tam nějaký snapshot nemá moc smysl :)

A tohle systemd podle mě zvládne.

Zvládne, ale to co jsem psal bylo, že původní init to zvládal bez nutnosti to explicitně konfigurovat, protože to udělal už tvůrce toho init skriptu. A protože jsem slíbil, že nebudu flamovat, tak se zdržím poznámek o LP a jeho přístupu

P.S. Teď mi to vše funguje k plné spokojenosti, ale objektivně to bylo složitější u té Fedory17 než u té Fedory13 - a to i když nepočítám čas a námahu vynaloženou na studium nové věci...

[pavlix]

Já zase můžu vyjmenovat spoustu důvodů, proč je síťový root dobrý nápad.

Zde nejsme ve sporu.

Ty virtuály tu síť už potřebovat nemusí, navíc na ní nemusí být závislé...

V tom rovněž nejsme ve sporu. Pouštět virtuály až po nastavení sítě a ukončovat je ještě předním podle mě ničemu nevadí. A netýká se to jen nastavení sítě, ale celé řady klíčových systémových démonů.

Já to tak i tak nepovažuju za moc ideální řešení, takže pokud se vypíná hostitel, vypnu i všechny stroje, stejně se většinou jedná o síťové servery, tam nějaký snapshot nemá moc smysl :

Já jsem to používal, protože to bylo rychlejší.

Zvládne, ale to co jsem psal bylo, že původní init to zvládal bez nutnosti to explicitně konfigurovat, protože to udělal už tvůrce toho init skriptu.

Stejně jako to může udělat tvůrce .service souboru.

A protože jsem slíbil, že nebudu flamovat, tak se zdržím poznámek o LP a jeho přístupu

Ale o tom si klidně zaflejmovat můžeme. V říjnu se s ním nejspíš podruhé potkám osobně :).

P.S. Teď mi to vše funguje k plné spokojenosti, ale objektivně to bylo složitější u té Fedory17 než u té Fedory13 - a to i když nepočítám čas a námahu vynaloženou na studium nové věci...

Problém je v tom, že systemd pořádně nikdo neumí. Ani tvůrci software, ani maintaineři balíků. Viz ten problém s automatickým startováním NetworkManageru po service NetworkManager stop. Vůbec to nebyla chyba systemd, ale dokud nám nepomohl michich, tak jsme byli úplně v háji. Pak to podle toho samozřejmě ve Fedoře vypadá.

Podle mě je správná cesta hlásit bugy na konkrétní projekty a snažit se docílit toho, aby byla funkční konfigurace už v distribuci, jako tomu bylo u sysvinit.

[Radek Hladik]

V tom rovněž nejsme ve sporu. Pouštět virtuály až po nastavení sítě a ukončovat je ještě předním podle mě ničemu nevadí. A netýká se to jen nastavení sítě, ale celé řady klíčových systémových démonů.

Rejp: Tohle mi připadá trochu v rozpouru s tím, že se ty závislosti přeceňují...

Stejně jako to může udělat tvůrce .service souboru.

Jak jsme se shodli výše, pouze za cenu všelijaké černé magie nebo jiných nepěkných hacků.

Ale o tom si klidně zaflejmovat můžeme. V říjnu se s ním nejspíš podruhé potkám osobně :).

Já jsem ho osobně viděl na přednášce kdysi na Fosdemu, už jsem tu o tom i někde psal, pročetl jsem hodně článků na jeho blogu a musím říct, že kdybych nebyl nucen, tak si o tak arogatního člověka ani neopřu kolo...

Problém je v tom, že systemd pořádně nikdo neumí.

Problém je v tom, že systemd pořádně nikdo neumí, ale přesto už je ve fedoře tři verze jako defaultní init. Druhej problém je, že kdyby to tak nebylo, tak by systemd neměl ani zdaleka tolik nedobrovolných testerů, protože kdyby si lidi mohli svobodně vybrat.... Jestli s ním budeš mluvit, tak se ho zeptej, jak se mu podařilo systemd protlačit do fedory v tom stavu v jakém byl... Můj osobní tip je, že něco věděl na celou Fedora Steering Comittee

[pavlix]

Rejp: Tohle mi připadá trochu v rozpouru s tím, že se ty závislosti přeceňují...

Rejp: Mně :).

Jak jsme se shodli výše, pouze za cenu všelijaké černé magie nebo jiných nepěkných hacků.

Ne. Může to udělat pomocí systému závislostí, který systemd nabízí a pomocí sdružení více služeb pod target.

Já jsem ho osobně viděl na přednášce kdysi na Fosdemu, už jsem tu o tom i někde psal, pročetl jsem hodně článků na jeho blogu a musím říct, že kdybych nebyl nucen, tak si o tak arogatního člověka ani neopřu kolo...

Uvidíme, co si na nás vymyslí.

Druhej problém je, že kdyby to tak nebylo, tak by systemd neměl ani zdaleka tolik nedobrovolných testerů, protože kdyby si lidi mohli svobodně vybrat....

Oni si lidi můžou svobodně vybrat. Tedy aktivní lidi :). Lze používat distribuci, která vyhovuje a v ní nástroje, které vyhovují.

Jestli s ním budeš mluvit, tak se ho zeptej, jak se mu podařilo systemd protlačit do fedory v tom stavu v jakém byl...

Myslím, že budu mít lepší věci na práci.

Můj osobní tip je, že něco věděl na celou Fedora Steering Comittee

Já jsem zase slyšel, že FSC schvalovala prakticky všechno, co jim přišlo na stůl, zvlášť od dlouhodobých aktivních přispěvatelů. Chtěl jsem dodat ještě něco, ale vynechám to z důvodu svého současného zaměstnání.

[Radek Hladik]

Rejp: Mně :).

Syntaktický detail

Oni si lidi můžou svobodně vybrat. Tedy aktivní lidi :). Lze používat distribuci, která vyhovuje a v ní nástroje, které vyhovují.

To je klasický argument, který by byl pravda jen v případě, že by existovaly distribuce, které by pokrývaly všechny možnosti. V praxi je to tak, že se mi většina ostatních věcí na Fedoře líbí, ale kdyby někdo udělal Fedoru se SysV initem, tak bych to zvažoval

Chtěl jsem dodat ještě něco, ale vynechám to z důvodu svého současného zaměstnání.

Velice rozumné, viz ten chudák od Asusu v Alze

[pavlix]

Syntaktický detail

Nene, ztratilo se mi tam něco, mělo to být „mně ne“.

To je klasický argument, který by byl pravda jen v případě, že by existovaly distribuce, které by pokrývaly všechny možnosti.

Existují distribuce, které dávají uživateli hodně na výběr. Ale každá sranda něco stojí. Nicméně si myslím, že zrovna Fedora má mnohem větší problémy než systemd a to stejné se podle mě týká i dalších distribucí.

kdyby někdo udělal Fedoru se SysV initem, tak bych to zvažoval

Packaging guidelines ponechávají možnost zabalit sysvinit skripty do podbalíku se suffixem -sysvinit. Pokud by měl někdo dostatečný zájem, tak by se to teoreticky dalo.

Jediný problém vidím v tom, že Fedora je typicky distribuce, která se snaží o relativně jednotný setup, kdy se maintaineři soustředí převážně na funkci toho jednoho setupu. Fedora není Gentoo, které už v handbooku vybízelo vždy k výběru z několika záměnných produktů (například různé crony a syslogy).

Gentoo má už hodně let spolehlivý init systém, který je založený na skriptech a přitom má spoustu vlastností, které Fedora získala až se systemd.

Velice rozumné, viz ten chudák od Asusu v Alze

Jo to byla hodně velká tragédie.

Já jsem ale v trochu jiné pozici, už jen tím, že jsem do té firmy nastoupil, přestože jsem žádnou práci nesháněl. Navíc každou energii, kterou bych vložil nadáváním na kolegy, můžu místo toho vložit do zlepšování některého open source produktu z oblasti sítí.

Tím, že finance zdaleka nebyly hlavní motivací, by bylo divné, kdybych teď věnoval víc energie nadávání, než všemu tomu, kvůli čemu jsem do té firmy šel.

[Radek Hladik]

Existují distribuce, které dávají uživateli hodně na výběr. Ale každá sranda něco stojí. Nicméně si myslím, že zrovna Fedora má mnohem větší problémy než systemd a to stejné se podle mě týká i dalších distribucí.

Packaging guidelines ponechávají možnost zabalit sysvinit skripty do podbalíku se suffixem -sysvinit. Pokud by měl někdo dostatečný zájem, tak by se to teoreticky dalo.

Jediný problém vidím v tom, že Fedora je typicky distribuce, která se snaží o relativně jednotný setup, kdy se maintaineři soustředí převážně na funkci toho jednoho setupu. Fedora není Gentoo, které už v handbooku vybízelo vždy k výběru z několika záměnných produktů (například různé crony a syslogy).

To, že se Fedora snaží o jednotný setup je právě její největší síla. Věci jsou vyladěný dohromady a fungují. Všechny distribuce jako gentoo, kde si člověk může udělat kombinaci jakou chce, trpí právě tím, že každej pes jiná ves. Nikdo si pro to netroufne něco podporovat a špatně se to spravuje. Už proto je myšlenka dvou initů ve Fedoře nereálná.

Gentoo má už hodně let spolehlivý init systém, který je založený na skriptech a přitom má spoustu vlastností, které Fedora získala až se systemd.

Chápu, že pro desktop to může být jiné, ale na serveru mi opravdu vyhovovalo to, jak to dělal SysV se všemi těmi skripty. Služby se ovládaly přímočaře přes service a v "setup" existovalo textové klikáto, co spouštět. Z tohohle hlediska mi systemd přinesl opravdu jen starosti a čekám, kdy poprvé využiju nějakou jeho novou fičuru. Myslim opravdu využiju a ne, že mi server nabootuje o 5 vteřin rychlejc po tom, co to hodinu ladim

Nicméně si myslím, že zrovna Fedora má mnohem větší problémy než systemd

Upřímně řečeno, kromě systemd nemám s Fedorou na serveru žádný problém.

Navíc každou energii, kterou bych vložil nadáváním na kolegy, můžu místo toho vložit do zlepšování některého open source produktu z oblasti sítí.

Já si myslím, že dokud je to "nadávání" v konstruktivní rovině, tak minimálně přináší jiný pohled na věc. A když je to v rozumné míře, tak to naopak prospívá.

[Radek Hladik]

$ find /lib/systemd/ | grep online /lib/systemd/system/NetworkManager-wait-online.service /lib/systemd/system/remote-fs-pre.target.wants/NetworkManager-wait-online.service

Mimochodem, jaký je správný postup, jak se toho zbavit? Já jsem smazal link /lib/systemd/system/remote-fs-pre.target.wants/NetworkManager-wait-online.service a místo něj nalinkoval mojí network tedy /etc/systemd/system/network.service. To sice funguje, ale nevím, jestli to při upgradu nevezme za své...

Druhé, co jsem zkusil, je udělat si v /etc/systemd celý ten adresář remote-fs-pre.target.wants a dát do něj tu mojí network.service. Ten systémový se ovšem vezme v potaz, takže se při startu také spustí. Takže jsem si udělal lokální /etc/systemd/system/NetworkManager-wait-online.service , který volá /bin/true a je to...

Předpokládám, že jsem přehlédl nějakou jednoduchou alternativu, protože ani jeden tento postup není ideální...