Střípky z IT - (8) : Systemd : Uhádnete, kde byl problém? (diskuse)

[sdfsdf]

Duvod je, ze systemd je sracka. Byl tam Requires?

[Max]

Memyslím si. Nebyl.
Zdar Max

[Fms]

Dementní admin nainstaloval sračka systém se systemd.

[Max]

Dementní je ten, co nenastoupil do vlaku a přešlapuje na místě. Všichni ostatní už jsou dávno na cestě dál. Všechny nejpoužívanější distribuce používají systemd, který je odzkoušen a podporován v celé škále. Troufnu si tvrdit, že se jedná o pár procent uživatelů Linuxu, kteří se zbytečně něčemu brání. Je to podobné jako u jiných OS, kdy třeba uživatelé W2k nechtěli přejít na WXP, uživatelé WXP na Win7, uživatelé Win7 na Win10, uživatelé Win10 na Win11 atd.
Vždy se prostě najde určité procento lidí, kteří to prostě nedávají. Je to normální. Každopádně obhajovat to tím, že "všichni jsou blázni, jenom já jsem letadlo" je poněkud zvláštní :).
Zdar Max

[johnyK]

my to ve firme nyni take budeme pouzivat (zatim drzime centos6 pro zivote) a samozrejme nepujdeme hlavou proti zdi.

Presto si myslim neni vubec na zavadu, nyni po nekolika letech nasazeni, zkonfrontovat ty sliby pred zavedenim systemd s tim soucasnym stavem. Jestli si to dobre pamatuji, tak bylo receno, ze to bude bootovat rychleji a vubec to vsechno bude jakesi jednotne pres hranice distribuci a distribuce budou mit ulehcenou praci. Admini pry nebudou muset rozumnet desitkam ruznych bash-scriptu, jen se pro zcela zvlastni pripady seznami s tou syntaxi tech units a vetsinou se stejne prevezmou ty defaultni units.

Jak to tedy z meho pohledu dopadlo.

Server s centos 6 a nebo centos 7 bootuje stejne rychle a take se splnilo to, co ti zkusenejsi tvrdili - kvuli bootu jednou za 3 roky to skutecne nehraje roli.

Jako takovy normalni admin linuxovskych serveru jsem programoval jeden init-script asi tak jednou za 5 let. U systemd budu tedy muset editovat jedenkrat za 5 let nejaou unit. Uspora ??

U distribuci jsem hledal v poslednich letech zpravu, kolik man-power se rocne zavedenim systemd usetrilo. Bohuzel jsem podobne zpravy nenasel, neni to mozna tim, ze se uspory nekonaji??

Osobne musim spravovat centos6, nyni i centos7 a k tomu Slackware a FreeBSD. Uspora casu? Zjednoduseni prace? Bohuzel negativni vysledek.

Podle me je naprosto legitimni, kdyz lide vyjadri nazor k systemd takovym tim zkratkovitym zpusobem - totiz ze to nazvou srackou. Presto to vsichni budeme (muset) pouzivat a zivot jde dal. Jiste. Ale urcite by bylo vhodne si uvedomit co se skutecne stalo, aby se nejakym pristim systemd mohlo zabranit - jsou urcite dulezitejsi projekty.

[Max]

Ty to vidíš hodně z dálky. Rychlost asi byla zmíněna kvůli paralelnímu spouštění (asi se nejvíce projeví na desktopu, nevím, na serveru je to putna), jinak mně víc nenapadá.
Systemd přináší jednotnost napříč systémy, ulehčuje kontrolu běhu služeb, umožňuje je automaticky v případě pádu spouštět ( = nemusíš si psát watchdog scripty, neříkám, že je to běžné, ale některé zabugované sw, co je člověk nucen používat, občas padnou).
To, že napsat si unitu je jednoduché, netřeba zmiňovat. Podpora závislostí je také dobrá a kvůli paralelnímu spouštění nutná.
Editace systémových unit je čistá, prostě se vytvoří jen rozdílový soubor, ždáný systémový soubor neupravuješ, nemusíš ho duplikovat a upravovat apod.
Podpora systemd-nspawn se ve spoustě nasazení hodně ocení.
Osobně spravuji Debian, RHEL like 7 a 8 (šestky jsem se zbavil), FreeBSD. V privátu pak ArchLinux. Nějak jsem nezpozoroval rozdíly, problémy atd.
Systemd samozřejmě umožňuje více, než jsem nastínil, ale osobně to nějak víc neřeším.
Otázky ohledně legitimnosti měly a přišly před 8 lety. Tím to hasne, oldstable distro, jakým Debian je, měl systemd by default od verze 8 (rok 2015). Zahajovat tedy v dnešní době diskusi nad tím, zda systemd, jaký má přínos apod., je zhola zbytečné. Systemd je tady dekádu a stal se prostě už před spousty let standardem.
Zdar Max

[kvr]

legitimni, kdyz lide vyjadri nazor k systemd takovym tim zkratkovitym zpusobem - totiz ze to nazvou srackou

Legitimní to není, systemd není sračka, protože přináší jednoznačné benefity oproti původnímu SysV init (nebudu znovu vyjmenovávat).

jsem programoval jeden init-script asi tak jednou za 5 let. U systemd budu tedy muset editovat jedenkrat za 5 let nejaou unit. Uspora ??

Úspora je v tom, že ten unit poběží všude (bude-li mít správně nastavené a standardní dependencies) a nebudeš muset pokaždé vymýšlet číslo, které mu přiřadit, aby na daném počítači fungovalo. Což u pár počítačů asi nebude velký problém, ale vývojář software nezávislého na distribuci nemá naprosto představu, na jak obskurním setupu může software běžet.

PS: Já pořád nechápu tu averzi k systemd, co je s těma lidma? Kdysi jsem psal process manager (ještě v dobách před systemd) a deklarace pořadí byla dána závislostmi - nikdy by mě nenapadlo dělat jej přes čísla. Jako chápu, že u SysV initd kdysi dávno někdo zvolil čísla, ale obhajovat to jako lepší řešení, když dnes vedle sebe postavím číselné a deklarativní, to už musí být něco sakra špatně...?

[GeorgeWH]

PS: Já pořád nechápu tu averzi k systemd, co je s těma lidma?

- Pretoze sa to neda zo systemu odstranit.

- Pretoze je to proti filozofii Linuxu

- Pretoze uz to nie je len init system, ale zozralo to cely linux.

- Pretoze to nefunguje - centos, debian - bareos-fd/bareos-sd - pravidelne sa to pri restarte sluzby zasekne - jednoducho to ostane visiet (mozno aj do nekonecna, neviem, vzdy som to po nejakej dobe ukoncil Ctrl+c).

- Pretoze sa to rozbija - journald po zaplneni disku stale obsahuje cast logov este z aprila. Aj ked dam journal vacuumovat na 1 mesiac, tak stale tam ten kus logu je.

- Pretoze clovek, ktory to navrhol isiel pracovat do MS (to je moj subjektivny nazor, ale podla mna to o niecom vypoveda).

[Max]

Obecně není s funkčností problém, takže někde asi děláš chybu. Dále systemd nenavrhoval jeden člověk a neprogramoval ho jeden člověk.
Zdar Max

[GeorgeWH]

Takze na dvoch roznych distribuciach, na x instalaciach, pri roznych verziach bareos, na cistej instalacii robim niekde chybu? Nezda sa mi.

Jasne ze ho nerobil jeden clovek, ale mne pride systemd velmi podobny windowsom - obrovsky blob, ktory robi vsetko, ale clovek si tam nemoze doladit jemne detaily. Ako napr. spominany journald - oproti rsyslogu a logrotate je to nekonfiguratelna sracka, ktora nefunguje.

[Max]

Mně to nepřijde jako obrovský blob. Je to hodně modulární. Má to drobné moduly a malé unity na spoustu věcí. Tj. spousta malých komponent, které dělají vždy jednu konkrétní věc.
Zdar Max
PS: pokud ti nevyhovuje journalctl, používej rsyslog a logrotate, nic ti v tom nebrání

[Jendа]

PS: pokud ti nevyhovuje journalctl, používej rsyslog a logrotate, nic ti v tom nebrání

Když nebude mít funkční journal s dostatečnou historií, tak kdykoli udělá systemctl start mojeslužba (které mimochodem nejde debugovat co vlastně přesně spouští, aby to člověk mohl zkusit ručně nebo se prostě podíval co se sakra děje) a nenaběhne to, tak si nemá jak vypsat, co to řeklo na stdout a stderr než to umřelo, ne?

[Max]

Ne, on si může journalctl přesměrovat to rsyslogu a pokračovat v logování tak, jak byl zvyklý.
Zdar Max

[Max]

Jinak varianta číslo 2 je to nastavit v rámci unity:

StandardOutput=append:/var/log/app/app.log
StandardError=append:/var/log/app/error.log

nebo:

StandardOutput=syslog
StandardError=syslog
#StandardError=inherit
SyslogIdentifier=<your program identifier> # without any quote
SyslogFacility=local4

Nebo pak jak jsem zmínil, tak globálně přesměrovat journald:

nano /etc/systemd/journald.conf
...
[Journal]
...
ForwardToSyslog=yes
MaxLevelSyslog=debug
...

Prostě možností je spousta. Buď lze přesměrovat jen něco, nebo všechno, nebo nezapisovat do journald, ale rovnou do souboru apod.
Přijde mi, že systemd má spoustu voleb a je na každém, jak si to nastaví.
Zdar Max

[Jendа]

Obecně není s funkčností problém, takže někde asi děláš chybu.

To není pravda, například neskipnutelné (e.g. zmáčknutím Ctrl+C na konzoli) čekání při bootu nebo absence základní funkčnosti v journalu jsou normálně oficiální vlastnosti.

[GeorgeWH]

Tento problem prave riesim aj ja a Poťer ti odkazuje [1], ze si mas pre kazdu sluzbu, ktorej logy chces riesit samostatne, spustit dalsiu instanciu journald (namespace). Takze v mojom pripade to bude cca >10 journald procesov. A Poťer to vymyslel este tak, ze tieto logy nie je vidno v "obycajnom" journalctl, ale musis zadat konkretny namespace (ako parameter).

[1] https://github.com/poettering/systemd/commit/cc4df240559aa56407ca0a0c5d2abf635b5ba477

[GeorgeWH]

Akurat vobec netusim, co so vzdialenymi logmi...

[kvr]

- Pretoze je to proti filozofii Linuxu

(zbytek přeskočím)

Co přesně je na tom proti filozofii Linuxu? "Filozifií Linuxu" je nastartovat systém a pustit klíčové procesy po startu systému. To dělá initd i systemd, systemd řekněme spolehlivěji a efektivněji. Ve skutečnosti, funkcionalita systemd by šla zjednodušit na to, co dělá initd, ale stejně to nikdo neudělá, protože se nikdo nechce vracet o desítky let zpátky. Stejně jako nikdo nejde zpátky do dob kernelu 2.0.x , přestože byl jednoduchý a každá část dělala přesně jednu věc, na kterou byla určena - jednoduše byl neefektivní... Byl devfs proti filozofii Linuxu? Jsou GPU drivery v kernelu proti filozofii Linuxu?

PS: Nechcu spadnou do flamewar. Je to jenom reakce na termín "filozofie Linuxu" a jeho ohýbání pro účely vlastní argumentace.

[Jendа]

To dělá initd i systemd, systemd řekněme spolehlivěji

Minimálně než byly odladěné různé problémy tak to s tou spolehlivostí nebylo moc slavné. Teď už jsem naštěstí dlouho na problém nenarazil, ale pokud někdo přecházel v období kdy to ještě nebylo ready, tak má pachuť dost velkou.

[podlesh]

Jo, to je známé pravidlo - verzím .0 je lepší se vyhnout, a u klíčových komponent je rozumné vyhnout se i verzi 1 a možná i dvě. Někdo dokonce říká že je lepší se vyhnout všem verzím které jsou prvočíslo, ale to už je trochu esoterika

A v jiném, byť příbuzném oboru platí: hru kupovat až když je ve slevě, případně GOTY edici.

[trilobyte]

Zajimavy, z pohledu uzivatele systemu, kterej ma ~1 % zastoupeni na trhu kritizovat "par procent uzivatelu", kteri neco delaji jinak.

[Max]

1% z 5 miliard je celkem hodně uživatelů. Navíc v případě Linuxu tam bývá větší poměr těch, co to mají i v rámci práce / správy. Takže pak se snaží podobné návyky přesouvat i tam. S kritikou tedy nevidím problém.
Zdar Max

[Ruža Becelin]

> Je to podobné jako u jiných OS, kdy třeba uživatelé W2k nechtěli přejít na WXP, uživatelé WXP na Win7, uživatelé Win7 na Win10, uživatelé Win10 na Win11

Zrovna u Windows to tak jednoduche nebylo - ono vetsinou v dobe, kdy uzivatele "meli" prejit na novejsi Windows, tak ty novejsi Windows postradaly funkcionalitu starsich verzi, parkrat jsem u toho byl v korporatu, co znamenal prechod z WXP na W7, nebo W7 na W10, o nedodelanych W11 nemluve, tem chybi (klasicky) 2-3 service packy, nez se na to pujde dat prejit.

O serverovych verzich nemluve.

Jasne, domaci uzivatele to resit vesmes nemuseli (pokud jim neprestala fungovat nejaka ta appka), ale firmy to resily hodne.

A od te doby, co si Microsoft dela beta-testery se svych uzivatelu, se ve firmach resi prechod na novejsi verze "az bude nezbytne nutne"...

A to rikam jako clovek, co momentalne prechazi na Almu 9 (tam kde to jde, napriklad na desktopech).

[Max]

Já mluvím o uživatelích, né o adminech ve firmě, nebo o migracích firemní sítě. Myslím, že to je jasné z toho, když píši "...uživatelé...".
Samozřejmě, že u některých uživatelů to bylo kvůli chybějícím věcem (zahozené staré kompatibilitě apod.), ale spousta z nich s tím měla a má problém proto, protože je to prostě jiný.
Zdar Max
PS: Ve firmě jsme hromadně přecházeli na Win10 v době buildu 1511 (10.11.2015)

[Michal]

Problemem byl, je (a snad uz prilis dlouho nebude) v tomto a mnoha jinych pripadech Lennart Poettering.

[VoDo]

problem je zenekdo neumi se systemd

[Max]

Neřekl bych. Řekl bych, že jej ovládám dobře včetně psaní vlastních unit, ladění apod. Ale pravdou je, že člověk se v tom aktivně pořád nerýpe, jelikož to prostě funguje, takže občas nějaký drobek uteče.
Zdar Max

[Petr Tomášek]

Uhádnete, kde byl problém?

Že systemd je sračka?

[panpanika]

odpoved nevim, jen bych nerad aby ses maxi dal odradit privalem retardu. blogy zajimavy, tesim se kdo uhadne.

[Max]

Mám dovolenou, ale ve frontě mám dost zajímavých technickcých článků, jen nerad vydávám něco, u čeho si nejsem na 100% jistý, že je to 100% dotažený. Takže většinu toho mám na 95% sepsaného a jen si snažím najít chvíli, abych tam dopsal vše, co bych tam chtěl mít.
Zdar Max

[Vlado99]

Čiste hádam: Nie ie dešifrovanie až ďalší krok, nasledujúci za local-fs.target?

[Max]

Ne, není. Původně jsem si to také myslel, ale ne.
Zdar Max

[ewew]

Bol problém v tom,že After= určuje len poradie a Requires= vyžaduje aby bol daná služba, proces už pri spustení aktívny.

[Max]

Ne.
Zdar Max

[:00 naska 12:25:00]

Uz je to nejaky rok co jsem psala vlastni unity na mountovani vsemoznych sitovych, mobilnich a jinych "nespolehlivych" disku.

Co se pamatuji, tak byl problem vzdy v tom, ze se ty podminky/preconditions a nakonec i strom zavislosti vyhodnotil pouze jednou. A pokud v okamziku tohoto vyhodnoceni vypadal stav jinak nez autorka (ja ) predpokladala, tak se nic nespustilo a bylo ticho.

Resenim bylo odebrat vetsinu zavislosti a jeste navic pro jistotu pridat nekolik "watchdogu" pro kazdou unitu (uz si nepamatuji jak se to v systemd jmenovalo - tusim, ze slovicko "restart" bylo v nazvech tech direktiv) pro pripady selhani sluzby, vypnuti sluzby, a dalsi "unexpected situations" atd. Take jsem tam davala nejake umele zpozdeni, aby se sluzba nerestartovala porad dokola, ale treba s pulsekundovym zpozdenim jako predchazeni "tight loop" potazmo treba i live locku.

Myslim, ze kamarad na techto unitach dodneska provozuje domaci NAS s LVM, RAID, sifrovanim atd. a mozna i dalsi stroje.

[Max]

Ne, v podmínkách ani unitách problém není.
Zdar Max

[Max]

Abych shrnul většinu komentářů:
1) systemd nepovažuji za sračku
2) kvíz není problém systemd
3) Lennart Poettering je mi šumák
Zdar Max

[stevo]

Celkom by ma zaujímalo rozuzlenie. Momentálne riešim myslím že identický problém, len s inou službou. Samozrejme After a Requires mám správne. Služba je závislá od databázy a databáza... atď. Furt sa to točí dookola, kľudne aj niekoľko minút až to náhodou nabehne v správnom poradí. Nič nemám proti systemd. Som presvedčený že chyba je u mňa, medzi klávesnicou a stoličkou. Len nie a nie prísť na chybu.

Tvoje kvízy sa mi páčia a vždy sa niečo priučím. Nevšímaj si tých, čo im prší do nosa.

[Max]

Nemyslím si, že ti rozuzlením nějak pomohu. Kvíz se týká jen špatného pořadí mountování šifrovaného oddílu. Tebe zajímá kokrétní unita, která asi nijak nesouvisí s mountováním.
Pokud ruční kontrola nepomáhá, zkus systemd-analyze. Můžeš si i vygenerovat strom závislostí do pěkného svg takto:

systemd-analyze dot 'nfs-server.*' | dot -Tsvg > systemd.svg

Případně pak ještě konkrétněji:

# vygeneruje jen dependency "After=, Before="
systemd-analyze dot 'nfs-server.*' --order | dot -Tsvg > systemd.svg

# vygeneruje jen dependency "Requires=, RequiresOverridable=, Requisite=, RequisiteOverridable=, Wants=, Conflicts="
systemd-analyze dot 'nfs-server.*' --reuire | dot -Tsvg > systemd.svg

Atd. Jde si s tím dost hrát a znázornit si jednoduše pořadí, jak by mělo docházet ke spouštění.
Zdar Max

[GMT+3]

A co takhle treba pouziti /etc/fstab? Ta sluzba generujici (docasne) unity z fstabu (primo "za behu" tj. primo pri bootu pocitace) nikdy neresila dobre zavislosti a dodneska se domnivam, ze je neresi.

[Max]

Co konkrétně myslíš tím "A co takhle treba pouziti /etc/fstab?". Jak jsi napsal, ten se používá. Unita načte fstab a provede mapování. Závislosti řeší dobře, resp. jsem nenarazil na problém. Když tedy pominu tento kvíz, což jak jsem ale řekl, není bug, ale feature.
Zdar Max

[GeorgeWH]

Ja som musel do /etc/fstab pre GFS2 pridat parameter x-systemd.after=drbd.service, inac mi to stale pripajalo este pred tym, ako nabehlo DRBD.

[kolcon]

To odemykání a mountování trvá tak dlouho, že ty služby stačí zatím paralelně nastartovat?

[Max]

Ne, od toho existují ty závislosti v rámci unit. Otázkou je, proč to nefunguje :).
Zdar Max

[kvr]

Je to nějaké dvouúrovňové? Tedy, nejdřív se připojí disk, který sám splní local-fs.target a teprve poté se pustí encrypted loop volume a mount na něm?

Pokud jo, tak to znamená předefinovat dependencies tak, aby local-fs.target zahrnovala všechno včetně toho encrypted volume a nastavit dependencies z encrypted volume jenom na ten základní mount (nebo cokoliv to je).

[Max]

Vše je už správně nastaveno v rámci systemd, takže opravdu dojde správně k dešifrování a připojení partition a respektování "local-fs.target". Tedy za předpokladu, že člověk nemá zapnutou fci, která zapříčiní problém zmíněný v kvízu.
Zdar Max

[Ragzid]

Vubec nemam zkusenosti s sifrovanym btrfs ve fstabu. Takze jenom nahodim napady:

• local-fs.target preskoci radek ve fstabu kvuli nejake option (zalohovani, fsck, nebo fs_type)
• system nebezi jako multi-user.target, tudiz nedojde ke spravne instalaci behem systemctl enable
• chybi RPC sluzba pro NFS
• nejaka historicka zapomenuta rucne upravena sluzba, pripadne zamaskovana

A pak predpokladam, brtfs neni systemovy disk, ale pouze datovy? Pokud by byl systemovy, tak by mohl byt i problem v neaktualizovanem init ramdisku?

[Max]

Gratuluji, jsi nejblíže k cíli, takže to uzavřeme a napíšu řešení. Tím je skutečně jeden parametr ve fstab (řádek se ale nepřeskočí, ale zpracuje, kdyby se přeskočil, disk se nenamapuje vůbec). Konkrétně jde o parametr "nofail". Ten se používá, když chceme, aby OS naběhl, i když je s diskem nějaká chyba, nebo je s jeho mountováním problém (prostě připoj, když to nejde, nevadí, OS naběhne a nebude stepovat na erroru). Pokud si tedy někdo s něčím hraje, dočasně použije tento parametr a zapomene na něj, tak to má za následek to, že local-fs.target ho vyloučí ze seznamu čekání na dokončení. Připojení se tedy provede, ale může se stát, že opožděně a nějaká služba naběhne dřív a pak je problém.
Zdar Max

[Ragzid]

To me napadlo tez, ale jak nebyl k dispozici primo vypis z fstabu, nebo urceni disku (mozna jsem v diskuzi prehledl?), tak to uz byla divoka spekulace.

Dobre vedet do budoucna, kazdopadne se to chova, tak jak by clovek cekal.

[Max]

Výpis z fstab jsem sem nedával schválně, to už by bylo do očí blijící :).
Zdar Max

[ehmmm]

Od rana jsem cekal na reseni, dekuji.

A jde to nejak resit, kdyz "nofail" ve fstab chces nechat? Myslim nejak prepsat unitu.

[Ragzid]

jsem zvedav na Maxovo reseni, ale osobne bych pridal (v tomto konkretnim pouziti pro DLNA) pridal zpozdeni startu sluzby + upravit pozadovane zavislosti mezi NFS/DLNA/local-fs

Neco ve smyslu ExecStartPre=bash -c 'sleep 23s', pripadne zkusit vyuzit neco ze skupiny StartLimit*

[Max]

Mé řešení je nepoužívat nofail pro disky, na které jsou zavěšené služby :). Ono to totiž v opačném případě nedává smysl, ten parametr nofail používat. Každopádně dobré počtení jsou v issue, které na toto téma visí u RHELu a jinde. Viz třeba: #1725364.
Údajně by tedy mělo pomoci přidat do fstabu "x-systemd.before=local-fs.target". Ale nezkoušel jsem.
Definování sleepů nebyl nikdy dobrý nápad, takže k tomu bych se neuchyloval.
Zdar Max

[MP]

x-systemd.* parametry v /etc/fstab pouzivam pro mountovane sitove disky pro nginx - samotny server mi tak nastartuje, i kdyz sitove disky jeste nejsou dostupne. Ma to i tu vyhodu, ze do takoveho adresare nelze pristupovat, dokud se nepripoji (tzn, nelze ulozit ta data na jiny disk nez sitovy). Takze by test kombinaci nofail + x-systemd parametru urcite stala za vyzkouseni.

[alkoholik]

S disky, ktere odemykame pres Clevis/TANG, jsem sel cestou cestou RequiresMountsFor.

[kvr]

Je tam aspoň nějaký warning v logu, že to systemd přeskakuje, respektive nečeká? Jestli ne, tak je to na troubleshooting docela náročné.

A jaké je přesně časování? Prostě to přeskočí a pustí o chvíli později nebo aspoň začne a nečeká na dokončení? Čekal, že tohle proběhne docela rychle (v případě, že se snaží hned) a měl by to stihnout před nastartováním dalších služeb - obvykle je jejich start komplexnější než obyčejný mount...?

[Max]

Vzhledem k tomu, že nejde o chybu, ani nějakou nepředvídatelnou věc, tak těžko můžeš chtít nějaký warning v logách.
Jinak spuštění nfs serveru nebo minidlna je rychlejší, než mount, takže jde o každou ms.
Zdar Max

[sdfgdsfg]

Tak to je zrovna prasarna. Protoze nofail nema byt vylouceno z cekani na dokonceni. Ma se na neho pockat a pak pokracovat bez ohledu na vysledek. Cili systemd je prasarna a ten co to navrhoval je picus stejne jako vsichni jeho simpove.

[Jendа]

Ma se na neho pockat a pak pokracovat bez ohledu na vysledek.

To je otázka, zejména když to čekání je nepřeskočitelné a pak člověk teče když čeká někde v mrazu/hluku u konzole než to napočítá do 90. Manuál taky píše boot will continue without waiting, ale manuály k systemd už mají ten syndrom co mají zákony, že je prostě člověk kvůli jejich objemu nemůže znát všechny a pak ho něco překvapí. A o kousek výš se asi píše jak z toho ven (ale nezkoušel jsem to), že i nofail záznamu můžeš dát x-systemd.before=nějaká_unita, a pak by to mohlo počkat a až pak spustit ten NFS server nebo co to tam Max měl. Ještě teda nevím jak je to s pokusem o další spuštění - třeba by NFS server měl že když selže, tak se to po 10 sekundách restartuje, ale když se nepodaří ten mount, tak se NFS možná ani nedostane do toho failed stavu kdy by se zkoušelo otáčet (spolu se svými závislostmi). Vida, taky by to asi šlo vyřešit tím, že se NFS dá after=ten_mountpoint, ne?

[kvr]

Taky jsem původně přemýšlel nad odpovědí podobnou "sdfgdsfg", tedy bez toho závěru a generalizování...

Je pravda, že některé filesystémy můžou čekat dlouho než definitivně pokus vzdají, takže v tomto směru chování systemd dává smysl. Na druhé straně, pokračovat hned bez toho, aby vůbec dostaly šanci, je zjevně nesmysl. IMHO tam chybí dvě věci:

1. Timeout pro nofail (nebo spíš nofailOnTimeout) - pokud by se mount nepovedl třeba do 10s, tak by systemd nečekal a pokračoval dál. 2. Různé dependency pro různé disky. Byl zmíněný x-systemd.before nebo spíš možná líp x-systemd.wanted-by=advanced-fs.target a potom definovat MiniDlna jako after=advanced-fs.target . Co tam možná chybí, je nějaký standard - ale možná se pletu a něco už existuje...

[alkoholik]

Standard nechybi, MiniDLNA staci pridat RequiresMountsFor, aby si pockala na svoje adresare.

[Max]

Upravovat všechny potřebné unity nedává smysl. V mém případě jsou to dvě, v jiných to může být více.
Zdar Max

[Petr]

Tj, jenze co pise systemd manual uplne nesouhlasi s vyznamem nofail v puvodnim smyslu (aka v tom ve fstab). Cili si to systemd tak nejak upravil a predefinoval a vsichni ostatni "poserte se".