Fórum Root.cz
Hlavní témata => Desktop => Téma založeno: jmk 18. 01. 2018, 20:25:02
-
Ahoj,
následující situace:
v /etc/fstab mám záznam : 10.xx.xx.xx:/volume1/NAS /home/user/NAS nfs defaults 0 0všechno funguje. Přistupuji na mountpoint bez problémů.
Nicméně suspenduji, nebo vypnu NB a přesunu se mimo domácí síť a v tu chvíli jakmile NB chci probudit tak to tuhne při přihlašování na nekonečném timeoutu, protože to nemá dostupný ten mount. Tuším odkud vítr vane - systemD !
Netušíte, kde tomu geniálnímu systemD sdělit, že pokud není mountpoint dostupný tak čekej xx sekund a pak pokračuj dále?
Všude jsem se dočetl, že je to problém, či dokonce feature!? WTF!?, ale nikde žádné rozumné řešení.
Už jste to řešili, nebo jste se s tím smířili ?
Díky za nakopnutí.
-
Měl jsem stejný problém se ZFS ve fstabu - zfs service ještě nebyl najetý, tudíž se mount zcela nepodstatného adresáře nepovedl a systemd boot se zastavil na chybě - Ctrl+D ... Neřešil jsem to a dal mount přímo do zfs (místo legacy jsem nastavil konkrétní cestu). Taky nechápu, proč na tolika místech zkomplikovali boot. Opravdu se bojím systemd nasadit na produkční servery, protože budu trhnout, kdy se boot opět nepodaří z důvodu nějakého nesmyslu. Minule to byl nenastavený timeout síťovky, která nedostala od DHCP serveru IP adresu - opět zášvih bootu. Dá se to vyladit, ale je to všechno minimálně na druhý pokus. Defaultní chování systemd mi přijde prapodivné...
-
Mount option nofail.
-
Mount option nofail.
"jen" skoda ze v ere pred sYsTeMd byl option nofail vychozi hodnota, tedy i bez uvedeni u polozky ve fstab...
-
Měl jsem stejný problém se ZFS ve fstabu - zfs service ještě nebyl najetý, tudíž se mount zcela nepodstatného adresáře nepovedl a systemd boot se zastavil na chybě - Ctrl+D ... Neřešil jsem to a dal mount přímo do zfs (místo legacy jsem nastavil konkrétní cestu). Taky nechápu, proč na tolika místech zkomplikovali boot. Opravdu se bojím systemd nasadit na produkční servery, protože budu trhnout, kdy se boot opět nepodaří z důvodu nějakého nesmyslu. Minule to byl nenastavený timeout síťovky, která nedostala od DHCP serveru IP adresu - opět zášvih bootu. Dá se to vyladit, ale je to všechno minimálně na druhý pokus. Defaultní chování systemd mi přijde prapodivné...
A ktery system umi rozeznat (ne)podstatny adresar od (ne)podstatneho?
-
Mount option nofail.
"jen" skoda ze v ere pred sYsTeMd byl option nofail vychozi hodnota, tedy i bez uvedeni u polozky ve fstab...
A pak zhavarovaly serverove sluzby, protoze nemely datove disky, takze se to naopak muselo osetrit.
-
A ktery system umi rozeznat (ne)podstatny adresar od (ne)podstatneho?
Když to nedokáže, tak ať se do toho nesere a pokračuje.
A pak zhavarovaly serverove sluzby, protoze nemely datove disky, takze se to naopak muselo osetrit.
Ano, zatímco po Lennartově "vylepšení" zhavaruje celý server, pro jistotu ve stavu, který nelze vzdáleně nijak vyřešit. Tomu říkám pokrok.
Kretén vylízanej.
-
A ktery system umi rozeznat (ne)podstatny adresar od (ne)podstatneho?
Třeba tak, že je to vše kromě kořenového fs. Aby server aspoň naběhl a byla šance, že pojede sshd. potom se aspoň problém dá řešit vzdáleně a nemusí se řešit třeba přes půl republiky jak ten server nahodit. A kdo do té serverovny vůbec pojede.
-
Přesně tak, stačí, aby najelo sshd, tedy root adresář. Vzdáleně už se to pak vždycky nějak opraví.
Jo, od toho slouží síťové KVM. Nicméně jsou i stroje, které to nemají...
Mimochodem, neví prosím někdo o malém síťovém KVM, ke kterému by šlo připojit VGA/klávesnice a mělo to vlastní nakonfigurovatelnou IP adresu? Klidně jen na jeden stroj.
-
Měl jsem stejný problém se ZFS ve fstabu - zfs service ještě nebyl najetý, tudíž se mount zcela nepodstatného adresáře nepovedl a systemd boot se zastavil na chybě - Ctrl+D ... Neřešil jsem to a dal mount přímo do zfs (místo legacy jsem nastavil konkrétní cestu). Taky nechápu, proč na tolika místech zkomplikovali boot. Opravdu se bojím systemd nasadit na produkční servery, protože budu trhnout, kdy se boot opět nepodaří z důvodu nějakého nesmyslu. Minule to byl nenastavený timeout síťovky, která nedostala od DHCP serveru IP adresu - opět zášvih bootu. Dá se to vyladit, ale je to všechno minimálně na druhý pokus. Defaultní chování systemd mi přijde prapodivné...
A ktery system umi rozeznat (ne)podstatny adresar od (ne)podstatneho?
Nikdo po něm rozeznávání nechce. Pokud je to podstatné, skončí to na kernel panic, pokud nepodstatné, OS najede obvykle alespoň do stavu, kdy se to dá lokálně či vzdáleně nějak řešit. Ale ten "emergency" režim, do kterého to systemd hodí to není.
-
Když už převzali tolik projektů, mohli by pro emergency režim udělat vzdálený přístup přes ssh...
-
Když už převzali tolik projektů, mohli by pro emergency režim udělat vzdálený přístup přes ssh...
Ale přece není vůbec nutné, aby ten matlal plácal ještě nějaké systemd-sshd, to SSH by v drtivé většině najelo samo o sobě, jenže filozofie toho matlala je s uvažováním normálního člověka, který někdy něco vzdáleně spravoval, naprosto neslučitelná. Viz tentýž emergency režim kvůli tomu, že se tomu křápu nelíbil parametr předaný kernelu (https://bugs.freedesktop.org/show_bug.cgi?id=76935).
-
Samozřejmě jsem nemyslel jiné ssh než v systému (má klíče, konfiguraci atd.), ale nějak upravit závislosti jeho unity, aby najelo i v emergency režimu.
-
... Viz tentýž emergency režim kvůli tomu, že se tomu křápu nelíbil parametr předaný kernelu (https://bugs.freedesktop.org/show_bug.cgi?id=76935).
Výživná disputace, :).
Ale 'closed', problem 'solved', hurá.
-
... Viz tentýž emergency režim kvůli tomu, že se tomu křápu nelíbil parametr předaný kernelu (https://bugs.freedesktop.org/show_bug.cgi?id=76935).
Výživná disputace, :).
Ale 'closed', problem 'solved', hurá.
No jistě, vyřešeno za 1:23 h - prohlášeno za feature, bez ohledu na to, že to způsobuje nenabootovatelnost systému a debugovatelnost kernelu. Tak se řeší věci - proto někteří obhájci systemd argumentují (nízkým) počtem otevřených bugů u systemd :D
A super je reakce Linuse na to:
http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01331.html :D
-
Neškodilo by, podívat se, jak je to už nějaký pátek implementované. Dá se to stihnout pod 1:23h
-
Neškodilo by, podívat se, jak je to už nějaký pátek implementované. Dá se to stihnout pod 1:23h
Jakože máme přehlížet kauzalitu a to jak se to řešilo, včetně dementnímu přístupu vývojářů, než byli dotlačeni to vyřešit jinak (a mezitím se pokoušeli o to, aby to změnili v linuxovém jádře)?
Reagoval jsem na
... Viz tentýž emergency režim kvůli tomu, že se tomu křápu nelíbil parametr předaný kernelu (https://bugs.freedesktop.org/show_bug.cgi?id=76935).
Výživná disputace, :).
Ale 'closed', problem 'solved', hurá.
- čili téma je "Výživná disputace, ...". Nebo se na to nesmí reagovat, jen proto, že to ukazuje na vyšinutost developerů kolem systemd?
-
Ále, to byl jen takový hloupý návrh, aby nevznikl dojem, že je to stejně, jako před lety. Když už s tou věcí musíte žít, abyste věděl jak vypadá přítomnost. Napříště si dám na podobné nápady pozor.
-
Mount option nofail.
Tak bohužel toto nepomohlo. Chová se to úplně stejně - holt asi "dobrej" oddíl :-\ :-\
Jakmile mám mountpoint namountovaný a dám suspend a následně probuzení mimo dostupnost moutnutého sharu tak to vytuhne na přihlašovací obrazovce.
-
Hmm, tohle neumím odladit na jednu iteraci a více se jich v těch odborných komentářích k systemd ztratí. A jedna iterace by byla napsat sleep hook, takže se ten adresář před usnutím odmountuje.
Z dotazu není jasné, jestli to chcete vyřešit "nějak" nebo přijít na to, kde to visí. Druhá možnost bude náročnější. Ale jestli to je Bruce Willis v tom avatáru, tak to nebude nemožné ;-)
-
Mount option nofail.
Tak bohužel toto nepomohlo. Chová se to úplně stejně - holt asi "dobrej" oddíl :-\ :-\
Jakmile mám mountpoint namountovaný a dám suspend a následně probuzení mimo dostupnost moutnutého sharu tak to vytuhne na přihlašovací obrazovce.
Tip (nemám teď kde odzkoušet): Zkusit ještě parametry soft a intr...
-
rád by jsem to vyřešil. Kde to visí to vím. Když se po několikerém pokusu náhodou dostanu do konzole (alt+ctrl+F1) a dám shutdown r --now tak v textovém výpisu to na umoutu toho sharu visí 90s - pěkně systemD odpočítává :-\ a pak restart doběhne.
intr, soft vyzkouším.
-
tak zabralo
intr,soft,timeo=1 čeká 1s a pak login normálně pokračuje.
@ByCzech - klobouk dolů ;)
díky všem za podnětnou diskusi a ty odkazy na jaderné vývojáře jsou fakt výživný ;D
-
https://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-nfs-client-config-options.html (https://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-nfs-client-config-options.html)
zde pěkně vysvětleno. ale to jsem našel, až teď ;D