Debian Stretch (Gnome) // systemD a nedostupný mount

[jmk]

Ahoj,
následující situace:
v /etc/fstab mám záznam :

Kód: [Vybrat]

10.xx.xx.xx:/volume1/NAS /home/user/NAS nfs defaults 0 0

vš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í.

[Reklama]

[dustin]

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é...

[Ladislav Michl]

Mount option nofail.

[nobody(ten pravej)]

Mount option nofail.

"jen" skoda ze v ere pred sYsTeMd byl option nofail vychozi hodnota, tedy i bez uvedeni u polozky ve fstab...

[MP]

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?

[Reklama]

[MP]

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.

[Lol Phirae]

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.

[Duff]

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.

[dustin]

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.

[ByCzech]

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í.

[dustin]

Když už převzali tolik projektů, mohli by pro emergency režim udělat vzdálený přístup přes ssh...

[Lol Phirae]

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.

[dustin]

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.

[hawran diskuse]

... Viz tentýž emergency režim kvůli tomu, že se tomu křápu nelíbil parametr předaný kernelu.

Výživná disputace,  .
Ale 'closed', problem 'solved', hurá.

[ByCzech]

... Viz tentýž emergency režim kvůli tomu, že se tomu křápu nelíbil parametr předaný kernelu.

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

A super je reakce Linuse na to:

http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01331.html