systemd: /etc/init.d/network vs. network-online.target

23.7.2014 14:55 | Přečteno: 1584× | linux/unix | | poslední úprava: 13.8.2014 09:26

Chystám se napsat pár více či méně faktických poznámek k závislostem na síťové konfiguraci v systemd ve vztahu k NetworkManageru a k síťovým skriptům se zvláštním důrazem na skripty ve Fedoře.

Rozlišuju několik kategorií systémových služeb podle jejich nároků na síťovou konfiguraci během jejich startu, tedy ještě než se od něj očekává zpracování požadavků. Podívejme se na ně od těch méně náročných po ty náročnější.

0) Ke svému spuštění síť nepotřebují.

1) Poslouchají na síti bez ohledu na interface a IP adresy, tedy poslouchají na adresách typu 0.0.0.0 nebo ::. Trochu váhám, zda nezařadit i služby, které poslouchají na localhost adresách, tedy 127.0.0.1 nebo ::1. Sem spadá drtivá většina služeb ve výchozí konfiguraci.

2a) Poslouchají na konkrétních adresách na základě explicitní konfigurace ze strany administrátora.

2b) Poslouchají na konkrétních adresách na základě detekce síťových rozhraní a jejich adres. Toto dělá například bind.

3) Připojují se k jiným službám na síti, často na základě předchozího DNS dotazu. To při bootu dělá například ntpd.

Znovu připomínám, že se zde zajímáme jen o potřeby během bootování. Například u DNS serveru je tedy důležité, na jakých adresách poslouchá, ale už není podstatné, kam se připojuje na základě DNS dotazu. Služby typu #0 a #1 dokážou naběhnout v libovolné fázi bootování, tudíž se budeme bavit o #2a, #2b a #3.

Navíc je tu trochu problém s tím, že typická služba typu #1 se pouhou změnou konfigurace může stát službou typu #2a.

Klasické řešení

Tradičně se toto řešilo tak, že během bootování skript plně nakonfiguroval síť a teprve potom se začaly podobné služby spouštět. Pokud se měnila síťová konfigurace, tak bylo řešením služby buď ručně restartovat nebo jejich restart naplánovat jako reakci právě na změnu síťové konfigurace.

Moje představa

Považuju za nesmysl, aby služby typu #2a čekaly na konfiguraci sítě jen proto, že jim kernel neumožní poslouchat na adrese, která v systému v danou chvíli není. A zjevně nejsem sám, vzhledem k existenci IP_FREEBIND. Já bych osobně byl pro to, aby taková volba byla výchozí konfigurací. Vzhledem k tomu, že to asi neprojde, tak by podle mě měly všechny služby typu #2a tuto volbu nastavovaly.

Služby typu #2b by mě měly při bootu chovat jako služby typu #0 nebo #1 a následně sledovat všechny změny síťové konfigurace (na Linuxu pomocí netlinku) a zařídit se podle nich dynamicky. Vím, že je to velký požadavek už z toho důvodu, že konkrétní způsob je na různých systémech různý. Už jen pro to by bylo nejdříve dobré eliminovat množství takových služeb. Osobně nevím o tom, že by některá služba toto skutečně potřebovala.

Služby typu #3 by se měly především být schopné srovnat se situací, kdy se spojení nezdaří a pokus opakovat. Osobně ale nepovažuju za úplně vhodné aby se pravidelně probouzela služba a snažila se komunikovat po síti, pokud je z aktuální síťové konfigurace zjevné, že se stejně nikam nepřipojí. Je otázkou, zda by se taková služba neměla spíše nechat probouzet službou na konfiguraci sítě. Takových služeb je minimum, takže bych to viděl jako rozumnou cestu.

Aktuální stav: NetworkManager

Je to jen pár měsíců, co se ve Fedoře objevil snapshot NetworkManageru s programem nm-online schopným počkat na dokončení, selhání či timeout všech síťových konfigurací určených k automatickému spuštění. To je velmi dobrý krok, nicméně ještě uvidíme, zda to funguje hezky na všechny typy připojení.

Integrace se systemd funguje tak, že služby, které potřebují počkat na síťovou konfiguraci, závisí (a čekají) na network-online.target, který dále závisí (a čeká) na NetworkManager-wait-online.service, který jednorázově spouští program, který zajistí čekání na síťovou konfiguraci.

To je věc, která ve Fedoře úplně nefunguje, protože většina služeb ještě postaru čeká na network.target (ten se naplánuje při bootu, tudíž závislost není potřeba). Vzhledem k tomu, že se jedná o targety systemd konfigurované v jednotkách (pro systemd), nezbývá než upravit všechny služby, které potřebují počkat na nakonfigurovanou síť, podle dokumentace a zajistit, že budou záviset na network-online.target a čekat na něj.

[Unit]
Wants=network-online.target
After=network-online.target

Jediný problém je v tom, že takováto závislost nejde vyjádřit v initskriptech, které systemd stále podporuje. Osobně jsem navrhl řešení, že závislost na $network v initskriptech nebude nadále znamenat čekání network.target, ale čekání a závislost na network-online.target. Ne úplně povedená aplikace tohoto řešení na Fedoru 20 způsobila problémy uživatelům network skriptů, viz dále.

Aktuání stav: /etc/init.d/network

Řešení pro bootovací skript je pochopitelně jednodušší, protože stačí počkat na jeho dokončení a zajistit, že skript neskončí dřív než je konfigurace připravená k použití. To víceméně funguje. Služby, které závisí na network-online.target a čekají na něj, dosahují se /etc/init.d/network stejných výsledků. Jako bonus platilo, že namísto výše popsaného stačilo nechat službu čekat na network.target.

Od systemd-208-18.fc20 dále se používá výše zmíněná změna významu závislosti na $network. Jako vedlejší efekt této změny přestala platit záruka pořadí /etc/init.d/network a network.target a tedy přestalo fungovat čekání na network.target i na instalacích, kde se NetworkManager nepoužívá.

Nabízí se hned několik řešení. Protože čekání nebo závislost na network.target zjevně nemá význam, je tak jako tak potřeba opravit všechny služby. Na druhou stranu by bylo dobré opravit i vedlejší efekt této dobře míněné změny, popřípadě změnu ve Fedoře 20 revertovat a řešit to v klidu pro další verze.

Závěrem

Situace ohledně síťových závislostí se nám začíná alespoň trochu konsolidovat. Všechny běžně používané služby na konfiguraci sítě od /etc/init.d/network až přes NetworkManager až po systemd-networkd korektně implementují network-online.target a kterýkoli jiný software se může s jeho podporou přidat. Navíc se teď počítá i s těmi, co používají libovolnou z uvedených služeb v kombinaci s vlastními initskripty závisejícími na $network.

Pokud jde o zmíněný problém se závislostí na síťové konfiguraci při použití /etc/init.d/network ve Fedoře, jedná se o zcela normální regresi, která byla výsledkem dobře míněné změny. Pokud by uživatelé podobné chyby hlásili místo planých výkřiků v diskuzích, nejspíše by ta chyba byla už dávno jedním nebo druhým způsobem opravena. Pokud by se navíc našli aktivní uživatelé, kteří by si instalovali verze z testingu, mohlo dojít k nápravě ještě než se chyba dostala do živých instalací uživatelů.

A teď se na mě můžete sesypat v diskuzi, že jsem vám svým návrhem nepřímo rozbil fidorku ;).

UPDATE 30.07.2014

Tak to vypadá, že systemd už má patch, který zajistí i původní řazení /etc/init.d/network před network.target. Zároveň mám potvrzeno, že je network.target stále užitečný, ale nikoli kvůli řazení při bootu, ale kvůli zpětnému řazení při shutdownu.

Pokud chce služba za běžných okolností podržet síť po celou dobu svého běhu a přitom nepotřebuje při startu obtěžovat s čekáním na skutečně připojenou síť, měla by použít:

[Unit]
After=network.target

Jako vedlejší efekt bude tato služba ale při startu čekat alespoň na spuštění služby na konfiguraci sítě, což je vzhledem k nulovým garancím zbytečné a trochu to kazí obrázek o dokonalém spouštění a zastavování služeb na základě závislostí, když musí člověk v některých případech nastavovat bootovací pořadí jen proto, aby se tím jako vedlejší efekt nastavilo pořadí pro shutdown. Zjevně neplatí předpoklad, že stačí jen obrátit pořadí služeb a shutdown bude fungovat automagicky*.

* Volný překlad Lennartovy oblíbené formule.

P.S.: To jak ábíčko prasí kód zápisků, aby se pak už nedaly rozumně editovat a ještě de facto obrací význam počáteční a ukončovací značky odstavce je fakt hnůj.

UPDATE (13.08.2014)

Takže pořadí mezi /etc/init.d/network a network.target je v upstreamu navráceno do původních kolejí a to především kvůli pořadí ukončování při vypínání systému. Jak je to s Fedorou zatím nevím.        

Komentáře

[rADOn]

Anzto v praci casto stridam wifi a metal rozumny chovani pri zmene site je jedna z veci proc jsem se na systemd docela tesil. Nic si z toho pavlixi nedelej, tohle bez rozbiti neceho udelat snad ani nejde.

[pavlix]

Anzto v praci casto stridam wifi a metal rozumny chovani pri zmene site je jedna z veci proc jsem se na systemd docela tesil.

Můžeš definovat rozumné chování při změně sítě a odkázat se na nějaký zdroj, který říká, že takové chování můžeme v souvislosti systemd očekávat?

Nic si z toho pavlixi nedelej

Z čeho?

[rADOn]

Můžu definovat ideální chování – když vypnu wifi čudlíkem a zastrčím ethernet, tak se shodí jeden iface, nahodí druhej a neupadnou mi vzdálený shelly

Obecně "rozumné" chování imo definovat nelze, představoval bych si spíš nějakého arbitra v userspace který by se staral o logiku, ale místo tlačení přímo do interfaců by ovládal správný initskripty (v nějaký podobě) a zároveň se sám z initu nechá ovládat (síťový profil == runlevel). Bez podpory initu něco takového samozřejmě nejde zrealizovat, takže když jsem slyšel že má systemd "vylepšit" init tak mě tohle napadlo jako přirozený kandidát. Co jiného by šlo vylepšit na initu?

Nic si z toho pavlixi nedelej

Z čeho?

Z toho že se na tebe teď všichni sesypou že jsi jim snědl fidorku. Nebo vůbec proto že trousíš takový sprostý slova jako systemd.

[trekker.dk]

Můžu definovat ideální chování – když vypnu wifi čudlíkem a zastrčím ethernet, tak se shodí jeden iface, nahodí druhej a neupadnou mi vzdálený shelly

Můžeš zkusit multipath TCP.

[rADOn]

Jasne, ale v tomhle pripade jsem mel na mysli spis jak takovou vec propojit se zbytkem systemu. Pokud mozno lepe nez modnim "praskneme tam dbus a dal to neni nas problem".

[St4nd3l]

Na spojení WiFi a ethernet (přecházení mezi něma) používam bonding. Muj konfig je tedy bond WiFi + Ethernet (ten je jako vychozí) do jednoho iface. Kdykoliv odpojim metal tak jedu přes vzduch bez vypadku. Samo je to podminěno tím, že jsem na stejnem subnetu. Takže třeba v práci ověření 802.1X jak metalicky tak na WiFi.

[Michal Kašpar]

To bych se zeptal na jednu věc. Když jsem tohle zkoušel, tak jsem se na takto připojený počítač nedostal z WiFi, pokud byl aktuálně připojený přes kabel. Vám toto funguje bez problému?

[St4nd3l]

Ano funguje. Zaklad je že máte jednu IP a ta funguje buď přes eth nebo wifi. Zaklad tedy je, že WiFi a eth je jedna logická síť (stejný subnet). Pak vám musí komunikace fungovat v pořádku. Bond mám nakonfigurován jako active backup. Konfigurace v debianu:

auto bond0
 iface bond0 inet dhcp
 bond-slaves eth0 wlan0
 bond_mode active-backup
 bond_miimon 100
 pre-up /etc/network/wpa_suplicant

[pavlix]

O tom bondingu už jsem hodněkrát uvažoval, ale nedostal jsem se k tomu to pořádně vyzkoušet. Pokud jde o multipath TCP, tak současný stav považuju za proof of concept s nulovou integrací do systému. Doknoce si myslím, že by multipath TCP měl řešit především kernel za jen lehké pomoci ze strany userspace, ale to současnému stavu vůbec neodpovídá.

[Michal Kašpar]

Tak to s tou jednou IP je jasné. Prostě bonding se slave eth a wlan a na něm IP. Jenže to mi právě takhle zlobilo. Prostě to vypadalo, jako by se věci připojené přes WiFi snažily připojit na to neaktivní wlan rozhraní. Nicméně asi to zas někdy zkusím, až budu mít chvíli času, když to někomu funguje.

[pavlix]

Prostě to vypadalo, jako by se věci připojené přes WiFi snažily připojit na to neaktivní wlan rozhraní.

To může asi dost záležet na konkrétním AP.

[xkucf03]

Dá se tohle udělat i nějakým GUI klikátkem, aby to bylo použitelné pro běžné uživatele na noteboocích?

[xkucf03]

Můžu definovat ideální chování – když vypnu wifi čudlíkem a zastrčím ethernet, tak se shodí jeden iface, nahodí druhej a neupadnou mi vzdálený shelly

Kvůli tomuhle jsem před lety myslím používal Wicd

[pavlix]

Jak přesně bylo tohle ve wicd řešeno? Nikdy jsem to nepoužíval.

[xkucf03]

To právě nebyl bonding, ale dovolilo mi to si nakonfigurovat dvě spojení se stejnou IP adresou – a pak jsem se mezi nimi mohl přepínat a nespadla mi navázaní spojení (SSH atd.).

[pavlix]

Takové nastavení mi dělal NetworkManager, ale kernel si s tím už neporadil.

[xkucf03]

jj, to byl AFAIK (už je to dlouho) důvod, proč jsem musel používat Wicd.

Ono to není úplně čisté řešení, protože ti ta IP adresa z jednoho rozhraní zmizí, chvíli není nikde, pak se objeví na druhém rozhraní a jako zázrakem ta navázaná spojení přežijí. Ten bonding by byl asi lepší, ale chtělo by to nějakou podporu v NM, aby člověk nepřišel o možnost konfigurovat to přes GUI (třeba zadávání hesla k novým WiFi sítím atd.).

[Josef Kufner]

Já mám takto nastavený DHCP server. Prostě přiděluje dvěma MAC adresám stejnou IP adresu.

Funguje to pěkně, jen je potřeba vypnout ochranu proti ARP spoofingu, neboť ta přesně tomuto brání.

[pavlix]

Bavil jsem se o tom s více lidmi a jak v případě nějakého transparentního bondingu, tak v případě použití více adres vidím problém v tom, že to může a nemusí fungovat v závislosti na použitých síťových prvcích. To mě odradilo od možnosti navrhnout to jako standardní chování.

[Josef Kufner]

Jo, ono to je takový ošklivý hack. Možná by ale šlo udělat nějakou virtuální LAN, která by tohle dělala čistě a jen s minimální režií.

[pavlix]

Problém je v tom, že je potřeba toto řešit na obou stranách. Fajn by bylo mít standard podporovaný routery, jehož podpora by se ohlašovala co já vím v rámci DHCP na drátové i bezdrátové síti, ale i tak by se člověku mohlo stát, že do toho zapojí switch a celé to tím rozbije. Podle mě by bylo úplně nejlepší neočekávat od IP a TCP věci, které nedokážou zajistit.

[xkucf03]

Výchozí/standardní by to určitě být nemělo – už jen proto, že ten počítač neví, které WiFi a ethernety k sobě patří a určitě bych nechtěl, aby se to dělo nějak magicky samo na pozadí.

Ale když si nastavím dvě spojení, třeba Doma_eth a Doma_wifi, tak by bylo fajn tam mít volbu, že chci mezi nimi plynule přecházet a mít pořád stejnou IP adresu a zachovat navázaná spojení. Že to nemusí fungovat vždy a všude, není důvod k neimplementaci – stačí tam dát informaci o tom, za jakých okolností je tahle funkce použitelná (a přinejhorším to uživatel zkusí a když mu to nebude fungovat, tak to zase vypne).

[pavlix]

Ale když si nastavím dvě spojení, třeba Doma_eth a Doma_wifi, tak by bylo fajn tam mít volbu, že chci mezi nimi plynule přecházet a mít pořád stejnou IP adresu a zachovat navázaná spojení.

Co přesně k tomu chybí, abys to mohl nastavit?

Že to nemusí fungovat vždy a všude, není důvod k neimplementaci

Vývoj většinou neprobíhá tak, že se implementuje vše, u čeho není důvod k neimplementaci. Naopak musí mít implementátor dobré důvody k implementaci a maintainer dobré důvody k začlenění.

stačí tam dát informaci o tom, za jakých okolností je tahle funkce použitelná

Hloupé na tom je to, že se ty okolnosti špatně specifikují a ještě mnohem hůře ověřují. Bavíme se o zcela nestandardní funkcionalitě, která přinese užitek zlomku uživatelů a to ještě na bázi štěstí. To není zrovna lákavý use case.

[xkucf03]

Co přesně k tomu chybí, abys to mohl nastavit?

Když si chci v NM naklikat bonding, tak mi to nabízí jen Ethernet a Infiniband.

dobré důvody k začlenění.

Ty důvody jsou výše – nespadnou navázaná spojení, zvýší se rychlost, spolehlivost…

Bavíme se o zcela nestandardní funkcionalitě, která přinese užitek zlomku uživatelů

Kolik lidí používá SSH? Kolik jich má WiFi i ethernet? Nemyslím, že by jich bylo až tak málo. Navíc se to netýká jen SSH, jde i o různé chatování nebo telefonování, přenosy souborů atd. Nebo třeba když budeš odesílat velký e-mail (nebo soubor přes HTTP): zasuneš ethernetový kabel a zrychlí se ti to. Nebo vytáhneš kabel, přejdeš do jiné místnosti, zapojíš kabel do jiné zásuvky… a celou dobu přenos probíhá (i když chvíli pomalu přes WiFi) a nemusíš soubor posílat znova.

[Ondrej Santiago Zajicek]

IMHO to je cele sileny band-aid. Spravne reseni je jednoduche:

Pokud sluzba implicitne posloucha separatne na kazdem rozhrani, pak by mela sama registrovat vznik a rekonfiguraci sitovych rozhrani a nikdo by ji nemel kvuli tomu restartovat a notifikovat. To bylo prijatelne mozna pred deseti lety, ale ne dnes. IMHO by se to radsi ani bandaidovat nemelo - holt nekteri demoni jsou kvalitni a jini jsou sunt, bandaidovani tu suntovost akorat zakryje. Vyvojari distribuci by namisto bandaidovani meli bugreportovat upstream vyvojarum a pokud s tim upstream vyvojari nic neudelaji, tak uzivatelum namisto sunt demonu doporucovat kvalitni implementace.

Varianta 2a) je trochu special case, protoze tam od admina se ocekava, ze vi co dela. Pokud to nastavi do sunt demona, tak holt ho musi spoustet v prihodnou dobu, pokud to nastavi do kvalitniho demona, tak s tim neni problem.

Co se tyce bootovacich zavislosti, tak tu mam jeste veselejsi problem:

(NTP) demon pri startu se snazi resolvovat DNS jmeno ci spojit s uplink serverem. Jenze jeste nezkonvergovalo routovani (system pouziva OSPF a nema statickou default routu) a tak je vzdaleny DNS ci NTP server nedostupny. NTP demon to vzda a start selze. Konvergence routingu probehne zcela asynchronne na bootovacim procesu za cca 30 sekund. Priadne mohou existovat dalsi sluzby, ktere zavisi na startu NTP :–) .

[Ondrej Santiago Zajicek]

Ten priklad s NTP demonem je v podstate situace 3). Osobne si myslim, ze rozumne reseni je to, aby se v pripade selhani uvodni iniciace sluzba sama periodicky (defaultne treba s periodou 3 * timeout jednoho pokusu, coz bude typicky podstatne vic nez sekunda) zkousela se obnovit. Zavislost na konfiguracni demonu je zbytecny narust komplexity, stejne je mnoho situaci, ktere nepokryje. Napr. dostupnost DNS by mohl sice testovat treba tak, ze IP adresa DNS serveru je pokryta nejakou routou, ale stale je tu problem, ze se NTP server spoji s DNS serverem, ale neresolvuje jmeno, resp. je mu vraceno ze jmeno neexistuje - tedy konfiguracni problem neni lokalni. A i z toho by se kvalitni software mel prirozene zotavit.

I kdyz je pravda, ze konfiguracni demon by mohl slouzit aspon jako hint, ktery by u sluzby triggeroval dalsi pokus drive, nez by se k nemu sama periodicky dostala. Vyhodou by bylo, ze by nebylo treba zadny slozity mechanismus, stacil by signal.

[pavlix]

Ten priklad s NTP demonem je v podstate situace 3). Osobne si myslim, ze rozumne reseni je to, aby se v pripade selhani uvodni iniciace sluzba sama periodicky (defaultne treba s periodou 3 * timeout jednoho pokusu, coz bude typicky podstatne vic nez sekunda) zkousela se obnovit.

Já jenom přemýšlím nad tím, jestli by alespoň u mobilních systémů nebylo vhodnější čekat na nějaký náznak změny, aby se ten proces neprobouzel zbytečně a celé plánování zůstalo na kernelu. Chápu, že u stabilních systémů na elektrické síti to nemá až takovou váhu.

Zavislost na konfiguracni demonu je zbytecny narust komplexity, stejne je mnoho situaci, ktere nepokryje. Napr. dostupnost DNS by mohl sice testovat treba tak, ze IP adresa DNS serveru je pokryta nejakou routou, ale stale je tu problem, ze se NTP server spoji s DNS serverem, ale neresolvuje jmeno, resp. je mu vraceno ze jmeno neexistuje - tedy konfiguracni problem neni lokalni. A i z toho by se kvalitni software mel prirozene zotavit.

Popravdě řečeno jsem o závislosti na konfiguračním démonovi nikde nepsal, ani o tom, že by se služba neměla zotavit v případě, že doplňkové informace získat nemůže. Vždycky je tu přeci možnost periodického pollingu a pokud vím, tak ntp ho provádí i v případě úspěchu.

I kdyz je pravda, ze konfiguracni demon by mohl slouzit aspon jako hint, ktery by u sluzby triggeroval dalsi pokus drive, nez by se k nemu sama periodicky dostala.

Přesně tak. Navíc jsem tiše předpokládal, že stabilní instalace nepotřebují tak rychlé zotavení jako mobilní, takže by se daly ty periodické časy podržet relativně dlouhé. Zda by bylo užitečné aby démon věděl, že polling provádět nemusí vůbec, zůstává otázkou.

Nicméně je potřeba rozlišovat praktické otázky, kdy je kombinace pollingu a urychlení signálem dostatečným řešením a optimalizaci, kdy může mít smysl minimalizovat probouzení služeb jen na případy, kdy to má nějaký smysl.

Já jsem třeba před rokem vykopal z NetworkManageru vteřinový timer na reload informací z kernelu, který obcházel nějaké problémy s tím spojené a jsem na to celkem hrdý, ačkoliv to ve skutečnosti nemá zásadní praktický dopad, už jen proto, že jsem neauditoval celý kód, jestli tam není jiný podobně divoký timer.

[čavo]

Nejak som to nepochopil. Podľa tohoto popisu tam vlastne žiadny init systém ani nemusí byť. Init systém podľa tohoto má len všetky požadované služby paralelne spustiť a nechať to na ne nech sa s tým nejako vysporiadajú. Že kopu z nich bude zbytočne páliť procesorový čas aktívnym čakaním a zdržovať ostatné služby, ktoré by mohli zatiaľ štartovať, je celkom podružné. Veď výkonu je dosť. A keď sa tam dá uspávanie pred ďalším pokusom, to už bude len rýchlosť štartovania, keď sa jednotlivé uspania nazbierajú.

[Ondrej Santiago Zajicek]

Podľa tohoto popisu tam vlastne žiadny init systém ani nemusí byť. Init systém podľa tohoto má len všetky požadované služby paralelne spustiť a nechať to na ne nech sa s tým nejako vysporiadajú.

Vsak taky to tradicni init v podstate tak dela. Ma akorat zakladni runlevely.

Že kopu z nich bude zbytočne páliť procesorový čas aktívnym čakaním a zdržovať ostatné služby, ktoré by mohli zatiaľ štartovať, je celkom podružn

O zadnem aktivnim cekani nikde nic nepisu. Co se tyce detekce novych rozhrani, tak tam je to normalni cekani na netlink socketu.

[čavo]

Podľa tohoto popisu tam vlastne žiadny init systém ani nemusí byť. Init systém podľa tohoto má len všetky požadované služby paralelne spustiť a nechať to na ne nech sa s tým nejako vysporiadajú.

Vsak taky to tradicni init v podstate tak dela. Ma akorat zakladni runlevely.

A ja som si myslel, že ich spúšťa sekvenčne (vporadí ako sú očíslované) a teda je akotaký predpoklad, že ďalší začne spúšťať až keď je predchádzajúca služba naštartovaná.

[pavlix]

Jediný důvod, proč na linuxu používat aktivní čekání?

[čavo]

Jediný důvod, proč na linuxu používat aktivní čekání?

Ups. Neuvedomil som si. Toto je o systemd, nie všeobecne o UNIX-e a jeho init-e. Ospravedlňujem sa.

Čiže všetky existujúce služby sa budú musieť, špeciálne, kvôli systemd prepísať. Lebo toto už bude zásah do služby a nie do spúšťacieho skriptu služby. Či nie?

[pavlix]

A odpověď?

[pavlix]

IMHO to je cele sileny band-aid.

Co máš namysli a co tím máš namysli?

Pokud sluzba implicitne posloucha separatne na kazdem rozhrani, pak by mela sama registrovat vznik a rekonfiguraci sitovych rozhrani a nikdo by ji nemel kvuli tomu restartovat a notifikovat.

Já si teda myslím, že by se služba měla nechat notifikovat ohledně změn síťové konfigurace. Jedinou jinou možnost vidím pravidelný polling, kdy se služba nechává místo toho notifikovat o uplynutí času a pak se ptá zbytečně.

To bylo prijatelne mozna pred deseti lety

Co?

ale ne dnes. IMHO by se to radsi ani bandaidovat nemelo - holt nekteri demoni jsou kvalitni a jini jsou sunt, bandaidovani tu suntovost akorat zakryje. Vyvojari distribuci by namisto bandaidovani meli bugreportovat upstream vyvojarum a pokud s tim upstream vyvojari nic neudelaji, tak uzivatelum namisto sunt demonu doporucovat kvalitni implementace.

Tady není řeč o nějakých vágních kvalitních či nekvalitních démonech ale o řešení zcela konkrétních situací, ať už na straně toho démona nebo v jiné komponentě systému.

Varianta 2a) je trochu special case, protoze tam od admina se ocekava, ze vi co dela.

Ovšem nemám pocit, že by se očekávalo, že kvůli nastavení adresy v konfiguraci bude kopírovat systemd unit z /usr/lib do /etc a upravovat závislosti a řazení.

Pokud to nastavi do sunt demona, tak holt ho musi spoustet v prihodnou dobu, pokud to nastavi do kvalitniho demona, tak s tim neni problem.

Opět bych se místo vágních pojmů radši pohyboval v konkrétních vlastnostech.

(NTP) demon pri startu se snazi resolvovat DNS jmeno ci spojit s uplink serverem. Jenze jeste nezkonvergovalo routovani (system pouziva OSPF a nema statickou default routu) a tak je vzdaleny DNS ci NTP server nedostupny. NTP demon to vzda a start selze. Konvergence routingu probehne zcela asynchronne na bootovacim procesu za cca 30 sekund. Priadne mohou existovat dalsi sluzby, ktere zavisi na startu NTP :–).

To je vcelku přesná modelová situace pro #3, kdy jednak potřebuješ zajistit, aby se NTP démon vzpamatoval z té situace a navázal spojení znovu ve chvíli, kdy je už DNS v pořádku a může být i vhodné jeho start prvně odložit, aby se neznažil zbytečně. Není to sice stejná situace jako s NetworkManagerem a DHCP, navíc nemusí být žádoucí prodlužovat boot time o čekání na konvergeci, ale ta možnost tu je.

[Ondrej Santiago Zajicek]

Co máš namysli a co tím máš namysli?

OK, mozna muj rant se tykal trochu jineho (ale souvisejiciho) problemu - ani ne tak poradi pri bootu, ale obecne reakce na dynamicke zmeny konfigurace site. Tedy demon spadajici do kategorie 2b by se mel stejne dobre vyporadat s tim, ze ono sitove rozhrani se objevilo az hodinu po bootu, protoze uzivatel zasunul USB sitovku. Pokud se sluzba dobre vyporada s timto, tak uz je poradi inicializace pro bootu vcelku okrajova zalezitost.

Já si teda myslím, že by se služba měla nechat notifikovat ohledně změn síťové konfigurace. Jedinou jinou možnost vidím pravidelný polling, kdy se služba nechává místo toho notifikovat o uplynutí času a pak se ptá zbytečně.

Mozna jsem se nepresne vyjadril. Jde mi o pripady, kdy demon sam nepredpoklada nic o zmenach rozhrani (viz odpoved na 'misto vagnich pojmu' nize) a proto externi faktor (napr. konfiguracni skripty distribuce) ho k tomu sami musi donutit (napr. tim, ze ho reloaduji ci restartuji pri zmene - jako treba debiani /etc/network/if-up.d). Pokud demon potrebuje znat aktualni stav interfacu kvuli bindovani socketu, tak by se demon by se mel starat sam a to napr. nekterym z nasledujicich zpusobu (serazenych podle rozumnosti):

1) poslouchanim na netlink socketu na interface udalosti

2) periodickym scanovanim seznamu interfacu

3) periodickym pokusem o bind pokud drivejsi pokusy selhaly

To bylo prijatelne mozna pred deseti lety

Co?

Workaround, kdy to za demona resily distribucni skripty

Opět bych se místo vágních pojmů radši pohyboval v konkrétních vlastnostech.

Konkretni vlastnost je ta, ze demon predpoklada, ze vsechna sitova rozhrani existuji a jsou nakonfigurovana od jeho spusteni a od te doby se nezmeni, udela na zacatku scan a podle toho se ridi. Bud demon nema delat predpoklady o sitovych rozhranich (a bindovat na :: ci ::1), nebo ma monitorovat stav sitovych rozhrani prubezne a reagovat na zmeny.

[pavlix]

OK, mozna muj rant se tykal trochu jineho (ale souvisejiciho) problemu - ani ne tak poradi pri bootu, ale obecne reakce na dynamicke zmeny konfigurace site. Tedy demon spadajici do kategorie 2b by se mel stejne dobre vyporadat s tim, ze ono sitove rozhrani se objevilo az hodinu po bootu, protoze uzivatel zasunul USB sitovku. Pokud se sluzba dobre vyporada s timto, tak uz je poradi inicializace pro bootu vcelku okrajova zalezitost.

Liší se to nějak od toho, co jsem psal v zápisku?

1) poslouchanim na netlink socketu na interface udalosti

Tedy zjevně řadíš na první místo možnost v zápisku explicitně uvedenou.

Workaround, kdy to za demona resily distribucni skripty.

O žádných distribučních skriptech ani o ničem jiném specifickém pro konkrétní distribuce jsem nepsal.

Konkretni vlastnost je ta, ze demon predpoklada, ze vsechna sitova rozhrani existuji a jsou nakonfigurovana od jeho spusteni a od te doby se nezmeni, udela na zacatku scan a podle toho se ridi. Bud demon nema delat predpoklady o sitovych rozhranich (a bindovat na :: ci ::1), nebo ma monitorovat stav sitovych rozhrani prubezne a reagovat na zmeny.

To v podstatě popisuješ rozdíl mezi #1 a #2. V případě použití IP_FREEBIND dokonce mezi #1/#2a a #2b.

[Ondrej Santiago Zajicek]

Zkusim se vyjadrit znova, strucne a snad jasneji. Pises:

Služby typu #2b by mě měly při bootu chovat jako služby typu #0 nebo #1 a následně sledovat všechny změny síťové konfigurace (na Linuxu pomocí netlinku) a zařídit se podle nich dynamicky.

Pointa meho prvniho postu byla ta, ze sluzby tupu #2b, ktere to tak nedelaji, by uz dnes mely byt bez omluvy povazovane za rozbite a neni treba na ne z tohoto hlediska jakkoliv brat ohled ci se to snazit (z pohledu distributora) jakkoliv workaroundovat.

[pavlix]

Pointa meho prvniho postu byla ta, ze sluzby tupu #2b, ktere to tak nedelaji, by uz dnes mely byt bez omluvy povazovane za rozbite

Souhlasím.

a neni treba na ne z tohoto hlediska jakkoliv brat ohled ci se to snazit (z pohledu distributora) jakkoliv workaroundovat.

Tady už jako (mimojiné) fedoří maintainer souhlasit nemůžu. Představa, že distributor bude ignorovat některý software jen proto, že se v některém ohledu nechová správně, je moc hezká, ale trochu naivní.

[miros]

Co se tyce bootovacich zavislosti, tak tu mam jeste veselejsi problem:

(NTP) demon pri startu se snazi resolvovat DNS jmeno ci spojit s uplink serverem. Jenze jeste nezkonvergovalo routovani (system pouziva OSPF a nema statickou default routu) a tak je vzdaleny DNS ci NTP server nedostupny. NTP demon to vzda a start selze.

O jakeho NTP demona se presne jedna? Neni to nahodou jen ntpdate, ktery se v nekterych distribucich spousti pri startu jako sluzba? Co znam ntpd a chronyd, tak oba zkousi prelozit jmena v rostoucich intervalech, ntpd navic posloucha na netlinku, takze by mel reagovat okamzite.

[Ondrej Santiago Zajicek]

OpenNTPD

[TM]

Já nadávat nebudu, protože děkuju za užitečný článek. Svůj názor na ohavné systemd a zbytečné problémy kolem jsem už ventiloval dostatečně.
Zabýval jsem se něčím podobným(šlo ale o shutdown systému nikoliv boot, se službou, která potřebovala před ukončením udělat nějakou práci na síti) při řešení problému v OpenSUSE 13.1 - krátce jsem to už nastínil před nějakým časem v jiné diskusi...
Čisté řešení jsem nenašel, pouze svůj vlastní prasácký workaround u kterého jsem zatím zůstal.
Proč je to vůbec v blogu? Byla by z toho dobrá série článků. Se systemd musíme žít a autor je téměř u zdroje... třeba by mohl tomu nějaký čas věnovat a RedHat by nic nenamítal, pokud by to bylo v pracovní době

[pavlix]

Svůj názor na ohavné systemd a zbytečné problémy kolem jsem už ventiloval dostatečně.

:)

Zabýval jsem se něčím podobným(šlo ale o shutdown systému nikoliv boot, se službou, která potřebovala před ukončením udělat nějakou práci na síti) při řešení problému v OpenSUSE 13.1 - krátce jsem to už nastínil před nějakým časem v jiné diskusi...

Popravdě řečeno toto lennart nenápadně v manuálu uvádí jako důvod pro použití network.target namísto network-online.target u služby, která potřebuje zajistit pořadí při shutdownu namísto při bootu. Je možné, že je to i důvod, proč prostě nedal novou sémantiku network.target a vytvořil network-online.target.

Proč je to vůbec v blogu? Byla by z toho dobrá série článků. Se systemd musíme žít a autor je téměř u zdroje... třeba by mohl tomu nějaký čas věnovat a RedHat by nic nenamítal, pokud by to bylo v pracovní době

V blogu je to proto, že jsem to ze sebe vysypal a už jsem to po sobě ani nečetl. Uvažoval jsem o článku, ale ten bych nabídl spíše fedora.cz a věnoval mu podstatně víc času.

[little.owl]

Ano, pokud si vzpominam, NetworkManager-wait-online.service byl spousten pred network.target a network-online.target; tedy NetworkManager-wait-online.service zbrzdil vsechny unity startovane po (After) network.target. Nevim jak je to presne ted - musim se doma kouknout - v praci je uz Fedora rozhodnutim IT borcu ilegalni - ale nektere [moje rychloulipane] sluzby, zejmena s pomalejsi startem, mohou zacit nabihat i kdyz sit neni jeste plne nakonfigurovana, a tohle pak muze byt zbytecne zpozdeni.

[pavlix]

Ano, pokud si vzpominam, NetworkManager-wait-online.service byl spousten pred network.target a network-online.target

Pokud mluvíš o nedávné době, tak se NetworkManager-wait-online.service nespouštěl vůbec, pokud (a) služba nevyžadovala network-online.target nebo (b) uživatel explicitně NetworkManager-wait-online.service nepovolil. Je to kvůli tomu, že v případě timeoutu některého připojení se čas bootování prodlužuje o ten timeout a tím kazí číslíčka ohledně doby bootování.

Trend je takový, aby už nikdo explicitně NM-w-o.service nepovoloval a jen minimum služeb ho vyžadovalo prostřednictvím network-online.target. Dá se říct, že Lennart považuje komponenty systému, které vyžadují network-online.target, za špatně navržené.

[little.owl]

Updated F19, unor. Problemy se tam vznikly kvuli OpenLDAP, ktery v dane sitove konfiguraci a jak byl nastaven, potreboval funkcni sitove pripojeni a proto NetworkManager-wait-online.service.

Pointa je v tom, ze jak network.target, tak network-online.target se spoustely po NetworkManager-wait-online.service - chapal bych to ale jen u network-online.target, nikoliv u network.target, ktery pak zbrzdil vse s After=network.target.

Proc nespustit NetworkManager-wait-online.service po network.target a network-online.target po NetworkManager-wait-online.service?

A to jak koukam je v git repo i network-pre.target. Ten se bude spouste po nebo pred NetworkManager-wait-online.service?

Dá se říct, že Lennart považuje komponenty systému, které vyžadují network-online.target, za špatně navržené.

V podstate bych s nim i souhlasil.

[little.owl]

Kdyz koukam do systemd 215 doc:

network-pre.target

    This passive target unit may be pulled in by services that want to run before
    any network is set up, for example for the purpose of setting up a firewall.
    All network management software orders itself after this target, but does not
    pull it in.

tak bych rekl ze pred NetworkManager-wait-online.service.

Jak by se to pak dalo dle tebe napasovat na tve scenare?

[pavlix]

Jak by se to pak dalo dle tebe napasovat na tve scenare?

Nerozumím otázce.

[little.owl]

Zkusim jinak.

Koncepcne tady mame tady tri klicove sitove targety, ktere jsou pouzivany k synchronizaci sluzeb pri startu:

network-online.target:
pro sluzby potrebujici ke svemu korektnimu provozu od pocatku funkcni sitove pripojeni (IMHO mizerne navrzene)
network.target:
pro sluzby potrebujici ke svemu provozu sit a jsou se schopny poprat s tim, ze sitove pripojeni neni v dobe startu k dispozici (dobre navrzene)
network-pre.target:
(a) pro potrebu neco jednorazove udelat drive nez je sit nakonfigurovana (napr. dynamicka HW konfigurace), (b) sluzba potrebuje byt spustena drive nez je sit nakonfigurovana (fabuluji, treba firewalld), (c) v situaci kdy z nejakeho duvodu Before=network.target proste nestaci.

Sluzby s initskripty by mely by default cekat na network-online.target, nebot se bude jednat o sluzby ktere fakticky nejsou plne kompatibilni se systemd a nelze nic predjimat. Povazuji to workaround a sluzby by mely zacit pouzivat systemd.

Ted se dovidam, ze network-online.target byl vlastne trochu omyl, i kdyz mne dava koncepcne smysl a tak mi neco unika.

Dale je tady vyjimecny systemd-networkd.service, ktery muze byt k dispozici uz i v initrd a se zajistenym bezpecnym prechodem do root, tedy moznost Before/After=systemd-networkd.service a pak veci kolem NM.

Jak by se to pak dalo dle tebe napasovat na tve scenare?

Nerozumím otázce.

Treba: Kdy maji byt korektne spousteny nektere sluzby se socket activaci, s bind na 0.0.0.0 a ::, pouzivajici IP_FREEBIND, ktere jsi zminil, v tomto novem scenari? Staci po network-pre.target?

Z toho vseho zacinam byt uz zblbly, budu si muset najit vice casu se na to podivat, nebot si prestavam byt jist, co jsou ted/do budoucna ty spravne synchronizacni body v After/Before= pro ruzne kategorie sitovych sluzeb, ktere jsi zminil.

[pavlix]

network.target:

pro sluzby potrebujici ke svemu provozu sit a jsou se schopny poprat s tim, ze sitove pripojeni neni v dobe startu k dispozici (dobre navrzene)

Přičemž jediný důvod pro network.target je pak shutdown, nikoli boot.

network-pre.target

To je ovšem relativní novinka a konfigurační služby na to ještě nejsou připravené, že? Na to se asi budu muset podívat...

v situaci kdy z nejakeho duvodu Before=network.target proste nestaci.

Obávám se, že naivní představa že network.target zahrnuje síť a tudíž lze použít na to, aby se něco udělalo před započetním konfigurace v praxi nefunguje a proto právě museli přidat network-pre.target, za který se pak ty konfigurační služby budou řadit.

Sluzby s initskripty by mely by default cekat na network-online.target, nebot se bude jednat o sluzby ktere fakticky nejsou plne kompatibilni se systemd a nelze nic predjimat. Povazuji to workaround a sluzby by mely zacit pouzivat systemd.

Ano, je to workaround, který jsem navrhl a který se skutečně týká jen služeb s initskripty.

Ted se dovidam, ze network-online.target byl vlastne trochu omyl, i kdyz mne dava koncepcne smysl a tak mi neco unika.

Záleží odkud se na to díváš. Technicky šel network.target reimplementovat jako network-online.target, ale tak jako tak by se musely opravit všechny služby. Na druhou stranu network.target teď umí podržet síť do ukončení služby bez zdržování při bootu, které je typickou vlastností network-online.target. Celé je to způsobeno požadavkem, že boot nesmí čekat na dokončení konfigurace sítě, jestliže v systému není nainstalovaná služba, která to vyžaduje, protože lennart chce rychle bootující desktop.

Treba: Kdy maji byt korektne spousteny nektere sluzby se socket activaci, s bind na 0.0.0.0 a ::, pouzivajici IP_FREEBIND, ktere jsi zminil, v tomto novem scenari? Staci po network-pre.target?

Tyto služby můžou být spuštěny kdykoli a nepotřebují se plánovat za žádný z těchto targetů.

[little.owl]

Přičemž jediný důvod pro network.target je pak shutdown, nikoli boot.

Z hlediska synchronizace ano.

Tyto služby můžou být spuštěny kdykoli a nepotřebují se plánovat za žádný z těchto targetů.

A neni dobre mit treba uz nastaveny firewall, predtim nez se spusti, tedy po network-pre.target - nebo kdovi kdy to ted bude?

[pavlix]

Z hlediska synchronizace ano.

Je nějaké jiné hledisko, na které bych měl brát ohled?

A neni dobre mit treba uz nastaveny firewall, predtim nez se spusti, tedy po network-pre.target - nebo kdovi kdy to ted bude?

To by na jednu stranu dávalo smysl, na druhou existuje basic.target, po kterém se by default řadí všechny jednotky a stačilo by tedy vynutit start firewallu před ním.

[Unit]
DefaultDependencies=false
After=sysinit.target
Before=basic.target

Takže je otázkou, zda je nutné synchronizovat takovéhle věci pomocí explicitní network-pre.target, když existuje implicitní synchronizační bod pro běžné služby.

[little.owl]

Je nějaké jiné hledisko, na které bych měl brát ohled?

Architektura. Asi se vyjadrim nepresne, ale libilo by se mi, pokud by dependency graph a sekvence pro sitove sluzby byly v urcitem smyslu izolovane od zbytku, respektive navazane jen pres urcite definovane body (jako jsou network-*.target).

[pavlix]

Podle mě se skutečně vyjadřuješ nepřesně a je potřeba především řešit reálné problémy a nevytvářet další. Pokud jde o architekturu, je především dobré nevytvářet nesmyslné požadavky, které ani nejdou vždycky splnit a tam, kde to jde, by se mělo cílit na univerzalitu. Já osobně souhlasím s tím, že celá tahle mašinérie je jen jeden velký systém workaroundů pro návrhové nedostatky software.

[little.owl]

Podle mě se skutečně vyjadřuješ nepřesně a je potřeba především řešit reálné problémy a nevytvářet další. Pokud jde o architekturu, je především dobré nevytvářet nesmyslné požadavky, které ani nejdou vždycky splnit a tam, kde to jde, by se mělo cílit na univerzalitu.

I u navrhu zavisloti mezi units/targets/etc. by se mely brat v uvahu urcite pozadavky na cohesion/coupling a nevytvaret nejake propletence. Jde hlavne o uzivatele, pokud struktura nebude jasna a mit logiku, budou sve unity nahodne dratovat a doufat, ze to nejak chodi.

Já osobně souhlasím s tím, že celá tahle mašinérie je jen jeden velký systém workaroundů pro návrhové nedostatky software.

To je jen jedna strana mince.

[pavlix]

Já osobně žádné propletence nevidím.

[pavlix]

Pointa je v tom, ze jak network.target, tak network-online.target se spoustely po NetworkManager-wait-online.service - chapal bych to ale jen u network-online.target, nikoliv u network.target, ktery pak zbrzdil vse s After=network.target.

Podle mě je v současné situaci použití After=network.target za účelem nastavení pořadí při bootu vždy chybou a je tedy při správné konfiguraci jedno, kdy se považuje za aktivovanou. Osobně bych na Lennartově místě jen redefinoval network.target a nesral bych se s přidáváním network-online.target, ale už se stalo.

Proc nespustit NetworkManager-wait-online.service po network.target a network-online.target po NetworkManager-wait-online.service?

Viz výše.

A to jak koukam je v git repo i network-pre.target. Ten se bude spouste po nebo pred NetworkManager-wait-online.service?

Proč se ptáš tady, když jsi měl otevřený kód?

[Radek Hladik]

Mně na tom zaujala informace o tom, že se ve Fedoře docela aktivně počítá s více mechanismy pro nastavování sítě. To by se mi moc líbilo, na notebooku NM a na serveru network script. Proto bych se chtěl zeptat, je k tomu někde nějaký "oficiálnější" popis? Přiznám se, že se ve Fedoří dokumentaci vždycky ztratim, ale na docs.fedoraproject.org je nejnovější Admin Guide pro F18 a tam se rovnou mluví o NM.

Když jsem na F17 vypínal NM a zapínal network skript, tak jsem si musel napsat unit file pro systemd, aby se to spouštělo před službama. Teď upgraduju všude možně na F20 a kdyby byl nějaký doporučený postup nebo tak, tak bych to rád udělal podle něj...

[pavlix]

Mně na tom zaujala informace o tom, že se ve Fedoře docela aktivně počítá s více mechanismy pro nastavování sítě.

Fedora nemá v tomto ohledu žádnou koncepci a víceméně jen reflektuje stav upstreamu plus do toho vrtá pár lidí, kteří se snaží to udržet nějak pohromadě. Upstream systemd zatím ještě potřebuje počítat s více nástroji na konfiguraci sítě z důvodu, že majoritu má NetworkManager a kvůli Intelu počítají s provozem ConnManu. Na initskripty z vysoka dlabou a počítají s tím, že konfiguraci určenou pro initskripty obhospodaří systemd-networkd, tak jako to teď dělá NetworkManager.

Proto bych se chtěl zeptat, je k tomu někde nějaký "oficiálnější" popis?

Kromě dokumentace systemd nic takového neexistuje.

nejnovější Admin Guide pro F18 a tam se rovnou mluví o NM.

Dokumentátoři se snaží nějak reflektovat měnící se distribuci a moc jim to nezávidím.

Když jsem na F17 vypínal NM a zapínal network skript, tak jsem si musel napsat unit file pro systemd, aby se to spouštělo před službama. Teď upgraduju všude možně na F20 a kdyby byl nějaký doporučený postup nebo tak, tak bych to rád udělal podle něj...

Pokud budou služby opravené, aby používaly network-online.target tak jak je uvedeno v blogu nebo se vypořádaly se spuštěním před dokončením konfigurace sítě, nebude uživatel muset dělat nic a bude to správně fungovat. Já si osobně myslím, že na ten jeden pitomý initskript /etc/init.d/network by kluci mohli tu systemd unitu napsat, popřípadě by někdo mohl na fedoru udělat bug report a tam přiložit unitu, která bude ten skript spouštět.

Ale trochu problém bude v tom, že jejich hlavním snem je initskript úplně odstranit a používat místo něj systemd-networkd, ale to bude v podstatě podobná situace jako s NetworkManagerem, jenom bude další služba pro obsluhu té stejné konfigurace. Efektivně tedy ani tak nenahrazují /etc/init.d/network, ale nahrazují NetworkManager ve funkci náhrady /etc/init.d/network.

[Radek Hladik]

Dokumentátoři se snaží nějak reflektovat měnící se distribuci a moc jim to nezávidím.

To je mi naprosto jasné a ani já jim to nezávidím.

Pokud budou služby opravené, aby používaly network-online.target tak jak je uvedeno v blogu nebo se vypořádaly se spuštěním před dokončením konfigurace sítě, nebude uživatel muset dělat nic a bude to správně fungovat. Já si osobně myslím, že na ten jeden pitomý initskript /etc/init.d/network by kluci mohli tu systemd unitu napsat, popřípadě by někdo mohl na fedoru udělat bug report a tam přiložit unitu, která bude ten skript spouštět.

Cožpak o to, já ten svůj unit file klidně poskytnu, ale zcela určitě ho nemám správně, co se týče správného pořadí spouštění, prostě jsem ho "frnknul," kde mi správně funguje (a to ještě na té F17, na F20 jsem ho zatím neupdatoval):

[Unit]
Description=good ol' network setup script
DefaultDependencies=no
After=local-fs.target
Before=sysinit.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/etc/rc.d/init.d/network start
ExecStop=/etc/rc.d/init.d/network stop
[Install]
WantedBy=sysinit.target

Ale trochu problém bude v tom, že jejich hlavním snem je initskript úplně odstranit a používat místo něj systemd-networkd, ale to bude v podstatě podobná situace jako s NetworkManagerem, jenom bude další služba pro obsluhu té stejné konfigurace. Efektivně tedy ani tak nenahrazují /etc/init.d/network, ale nahrazují NetworkManager ve funkci náhrady /etc/init.d/network.

Upřímně řečeno, ať jdou s další systemd-* někam, ale to je na jinou debatu. Já jsem spokojený s NM na desktopu a notebooku, ale probůh, do virtuálu s jednou/dvěma virtuálníma síťovkama, to bych si klidně i napsal shell script, který dvakrát zavolá ip Dokonce i používám staré pojmenování ethX a jsem spokojený, protože i kdyby se mi to přehodilo, tak mám buď virtuální konzoli nebo v případě fyzického serveru linkové IPv6....

Off-topic perlička na závěr: když jsem teď upgradoval nějakou starší Fedoru na F20 a po tom jsem dokonfigurovával apache, tak jsem zahlédl mod_systemd. Musím říct, že mě to trochu vyděsilo, ale když jsem si přečetl, co to má dělat, tak mně to docela uklidnilo, ale stejně...

[pavlix]

Když si vzpomenu, tak to někdy otestuju, ale jinak si myslím, že je dobré takové věci posílat spíše přímo do bugzilly.

[pavlix]

Ahoj, dovolil jsem si použít tvůj unit file v bugzille.

[Radek Hladik]

Jo a úplně jsem zapoměl poděkovat za zajímavé informace z Fedořího zákulisí, takže děkuju

[pavlix]

Fedora přece žádné zákulisí nemá ;).

[lnykryn]

Ještě je tam rozbitá jedna maličkost. Network initscript teď nemá ordering závislost na network.targetu a teoreticky se může při vypínání ukončit před ním.

[pavlix]

To vypadá jako stejný vedlejší efekt, jen pro shutdown.

[pavlix]

Mimochodem, o které politické straně musím psát, abych dostal tučňáka?

[xkucf03]

Tu máš tučňáky pro tvoje dva poslední zápisky

S politikou to nesouvisí¹. Nevím, jak ostatní, ale já je dávám u kvalitních zápisků, které jsem celé četl – nebudu to střílet jen podle nadpisu. A některé věci jsem buď nečetl, nebo jsem je četl na několikrát, po částech a pak na tučňáka zapomněl… Od toho je tu víc lidí s právem udělovat tučňáky – měla by zafungovat statistika a náhodný výběr a každý zápisek by měl projít alespoň přes jednoho admina a mít šanci na tučňáka (pokud vím, tak tu není nikdo, kdo by systematicky četl všechno a posuzoval, co dát do výběru).

_{[1] jako že stranu to vlastně volíš?}

[pavlix]

S tou politikou to byla trochu hloupá legrace. Nicméně už dlouho platí, že zápisky zjevně k tématu buď tučňáka nedostanou nebo ho dostanou až když si člověk řekne.

[xkucf03]

Nejsi v tom sám – některé moje zápisky taky nemají tučňáka, i když by mohly, jsou k věci a mají 100% nebo jinak vysoké hodnocení. Můžu si je tam sice dát sám, ale to by mě tolik nebavilo.

[pavlix]

Otázkou zůstává, k čemu pak ty tučňáci jsou.

[pavlix]

Když už jsme u těch CFLAGS, má někdo něco konkrétního k -O2 versus -Os versus -Og?

[pavlix]

Hmm, tak tohle se asi trochu minulo blogpostem... pardon.

[pavlix]

Vracím se ještě k tomuto postu. Díky všem za podnětné připomínky a rád bych vás, kteří se chystáte na LinuxDays pozval na takový malý followup (jistě ho v programu najdete).