Nedostupný server, zamrznutí, brute force ssh

[krakenpico]

Dobry den,
něco podobného jsem řešil s gigabyte brix. Jaky tam mate síťované karty intel e1000?

Ano, vypadá to tak

Kód: [Vybrat]

lspci -nn | grep -i ethernet
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (7) I219-LM [8086:15bb] (rev 10)

lshw -c network
WARNING: you should run this program as super-user.
  *-network
       description: Ethernet interface
       product: Ethernet Connection (7) I219-LM
       vendor: Intel Corporation
       physical id: 1f.6
       bus info: pci@0000:00:1f.6
       logical name: eno1
       version: 10
       serial: c4:65:16:a2:19:d4
       size: 1Gbit/s
       capacity: 1Gbit/s
       width: 32 bits
       clock: 33MHz
       capabilities: bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=6.15.1-1-default duplex=full firmware=0.5-4 ip=192.168.0.106 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
       resources: irq:145 memory:e1200000-e121ffff
WARNING: output may be incomplete or inaccurate, you should run this program as super-user.

[Reklama]

[jjrsk]

Pokud si pamatuju, tak inteli sitovky se nemely s tuxem rady, pokud na nich byl zapnuty rx/tx offload. Ale netusim estli se to tyce tvyho modelu.

zjisteni stavu
ethtool -k ethX

vypnuti
ethtool -K ethX rx off tx off

Edit:

Pripadne sem ted jeste nasel v poznamnicku ze problemovy muze byt totok
ethtool -K ethX tso off

[krakenpico]

Ano, měl jsem to zapnuté, zkusil jsem vypnout a uvidím, jestli to pomůže. Zatím díky

Pokud si pamatuju, tak inteli sitovky se nemely s tuxem rady, pokud na nich byl zapnuty rx/tx offload. Ale netusim estli se to tyce tvyho modelu.

zjisteni stavu
ethtool -k ethX

vypnuti
ethtool -K ethX rx off tx off

Edit:

Pripadne sem ted jeste nasel v poznamnicku ze problemovy muze byt totok
ethtool -K ethX tso off

[Michal Šmucr]

Nezdá se mi, že by s tím měl mít cokoliv společného RX, TX offload. Ale nevím, co myslel Peterekcze zmínkou o e1000 nebo e1000e (PCIe) ovladači.
1GbE síťovky od Intelu jedou s těmi zapnutými offloady naprosto běžně ve výchozí konfiguraci a jsou přítomné skoro na všech základních deskách s Intel CPU. V určitých specifických situacích offloady dává smysl vypnout (DPI firewally, zachytávání raw paketů..), nebo pokud to opravdu prokazatelně způsobí problémy (např. bude špatně fungovat škálování TCP okna). Nicméně to rozhodně není tak, že Intel síťovka => vypnu rovnou veškerý offload, to je blbost.
Další věc je, a zas se vrátím k tomu, co už jsem psal. Pokud by tohle nastalo, nejspíš by nevytuhl celý systém tak, že bude třeba vzít natvrdo tlačítkem a nikde nebude ani hláška. I pokud by systém např. po půl dni ztratil jen síťovou konektivitu, tak se krátkým stisknutím spustí normálně shutdown a systém se regulérně vypne, zapíše logy.
Což je i důvod, proč jsem navrhoval, ať se nejdřív zkusí vytížit a otestovat HW, a případně nasimulovat to vymrznutí, aby se tohle vyloučilo a neztrácel čas nějakými softwarovými tweaky naslepo (docker on/off, offload on/off..), zvlášť jestli to předtím fungovalo (předpokládám).

Ale třeba ještě Peterekcze vysvětlí, co měl konkrétně s tím Brixem a e1000.

[Peterekcze]

Nezdá se mi, že by s tím měl mít cokoliv společného RX, TX offload. Ale nevím, co myslel Peterekcze zmínkou o e1000 nebo e1000e (PCIe) ovladači.
1GbE síťovky od Intelu jedou s těmi zapnutými offloady naprosto běžně ve výchozí konfiguraci a jsou přítomné skoro na všech základních deskách s Intel CPU. V určitých specifických situacích offloady dává smysl vypnout (DPI firewally, zachytávání raw paketů..), nebo pokud to opravdu prokazatelně způsobí problémy (např. bude špatně fungovat škálování TCP okna). Nicméně to rozhodně není tak, že Intel síťovka => vypnu rovnou veškerý offload, to je blbost.
Další věc je, a zas se vrátím k tomu, co už jsem psal. Pokud by tohle nastalo, nejspíš by nevytuhl celý systém tak, že bude třeba vzít natvrdo tlačítkem a nikde nebude ani hláška. I pokud by systém např. po půl dni ztratil jen síťovou konektivitu, tak se krátkým stisknutím spustí normálně shutdown a systém se regulérně vypne, zapíše logy.
Což je i důvod, proč jsem navrhoval, ať se nejdřív zkusí vytížit a otestovat HW, a případně nasimulovat to vymrznutí, aby se tohle vyloučilo a neztrácel čas nějakými softwarovými tweaky naslepo (docker on/off, offload on/off..), zvlášť jestli to předtím fungovalo (předpokládám).

Ale třeba ještě Peterekcze vysvětlí, co měl konkrétně s tím Brixem a e1000.

Myslel jsem přesně toto co již zde bylo poslané: ethtool -K ethX rx off tx off

Toto me vyřešilo můj problém.

[Reklama]

[redustin]

@Peterekcze: Ta síťovka opravdu způsobila zaseknutí celého serveru, nebo jen nebyl přístupný po síti? Samozřejmě jsem se setkal se síťovkami, které se po čase začaly zasekávat a bylo nutné je vyměnit či místo nich (onboard) použít PCI(e) náhrady, ale nepamatuju si, že by zasekly celý systém (tedy stejně jak píše Michal).

Zato umírající zdroje na desce zasekávaly systém spolehlivě.

Otázkou je, zda by nebylo jednodušší řešení použít jiný komp. Vzhledem ke specifikaci CPU i5 asi nepůjde o žádné nenahraditelné serverové železo, přehodit disky a jede se dál.

[Michal Šmucr]

Myslel jsem přesně toto co již zde bylo poslané: ethtool -K ethX rx off tx off

Toto me vyřešilo můj problém.

Díky za upřesnění, pokud to vyřešilo problém, tak bezva a byla by to pro tazatele relativně jednoduchá úprava (třeba přes NetworkManager pro persistentní nastavení v SUSE Micro např. - nmcli con modify <spojeni> ethtool.feature-rx off ethtool.feature-tx off a následně nmcli con up <spojeni>).

Mám ještě pro zajímavost stejnou otázku jako teď redustin.
Jevilo se to u vás s Brixem podobně, tzn. zmrznul vám celý počítač bez jediné hlášky a musel jste ho vypnout natvrdo? Nebo "jen" ztratil konektivitu po nějaké době?

[krakenpico]

Tak i po vypnutí rx, tx a tso problém přetrvává. Byl jsem tam připojen přes ssh a měl výpis journalctl --follow, ale tam nic vidět nebylo. Zaměřím se ještě na tu diagnostiku hw přes live distro.

[Michal Šmucr]

Tak i po vypnutí rx, tx a tso problém přetrvává. Byl jsem tam připojen přes ssh a měl výpis journalctl --follow, ale tam nic vidět nebylo. Zaměřím se ještě na tu diagnostiku hw přes live distro.

Ještě jak jsem předtím zmínil ten stress-ng (měl by být na tom System Rescue live cd), mimo ten prime95.
Jeho výhoda je, že se ty jeho testy (stressory) nechají spustit najednou, když chcete vytížit celý systém.

Např. tohle (jen jsem to teď rychle splácal dohromady)

Kód: [Vybrat]

stress-ng -v --verify --metrics-brief --tz --hdd 4 --hdd-bytes 1G --hdd-opts wr-rnd,direct --temp-path /mnt/datavm/temp/ --matrix 0 --vm 2 --vm-bytes 50% --vm-populate --timeout 5m
První parametr nastaví verifikaci (pokud ji stressor podporuje), --tz ukáže statistiku teploty CPU, pak se tím --hdd zapne paralelní náhodný zápis (4 procesy, každý 1G), pak vytížení CPU s použitím matic (FPU, velký odběr) a automatickým počtem procesů podle počtu jader, pak vytížení pamětí přes --vm a nakonec celková doba trvání testu přes --timeout (jinak se zastavuje ručně přes ctrl+c).
Akorát až bych byl v živé distribuci, tak bych si někam ručně připojil ten Btrfs oddíl a upravil cestu v --temp-path, aby to zapisovalo na ta SSD.
Ale jinak je tam těch testů mraky, včetně třeba velké zátěže s obsluhou přerušení, tohle je jen rychlý výkop.

Uvidíte, jak se to bude případně chovat.

[jjrsk]

@Peterekcze: Ta síťovka opravdu způsobila zaseknutí celého serveru, nebo jen nebyl přístupný po síti? ...

Ja mam ve svym poznamnicku napsano, ze s temi offloady po nejaky dobe proste vytuhne kernel. Ale je to poznamka uz pomerne hodne letita, takze to nemusi platit pro aktualni stav.

S realtekama to problem neni protoze ty to neumej . (stema sou zase jiny potize)

měl výpis journalctl --follow

Obavam se, ze tohle je ti uplne nanic. I ve zdejsim propadlisti bys nasel ze pokud neco chcipne, tak tenhle pseudologer jde dolu jako prvni, takze zadny logy neuvidis. Musis jit niz abys mel sanci. dmesg je to co hledas. Samo ani to ti nemusi dat odpoved. A v idealnim pripade ten vypis nepoustecj pres ssh ale lokalne.

[LolPhirae]

Our jee, a teď sem naběhne Lennartův fanklub. 

[Michal Šmucr]

Obavam se, ze tohle je ti uplne nanic. I ve zdejsim propadlisti bys nasel ze pokud neco chcipne, tak tenhle pseudologer jde dolu jako prvni, takze zadny logy neuvidis. Musis jit niz abys mel sanci. dmesg je to co hledas. Samo ani to ti nemusi dat odpoved. A v idealnim pripade ten vypis nepoustecj pres ssh ale lokalne.

Ten tip byl ode mě původně v trochu jiném kontextu. Pokud má úplně headless systém a třeba to vytuhne tak, že už to vůbec nic nezapíše do persistentního logu na disku (vypadá to, že ne) a musí to natvrdo vypnout, tak přes ssh je alespoň nějaká šance zkusit přes druhý počítač odchytit, co se tam předtím stalo, jestliže ještě pojede síť (zatím opravdu nevíme, jestli je opravdu problém ta síťovka, jediné co tazatel popsal, je že počítač přestane reagovat).
A na tohle je ve výsledku už trochu jedno, jestli ve vzdáleném terminálu pustíš journalctl --dmesg --follow, jak jsem psal, nebo dmesg -w (byť dmesg je asi přímočařejší volba, co to netahá přes další buffer a sahá si rovnou na /dev/kmsg).
Samozřejmě je i pár dalších možností třeba forwardování na syslog server (což samozřejmě vyžaduje zas funkční síť), nebo na nižší úrovni přesměrovat konzoli na sériák a připojit se tam z jiného počítače terminálovým emulátorem.

[redustin]

Přes ssh jo, ale to by už asi musela být konexe otevřená před zátuhem, aby ssh nepotřebovalo sahat na disk. Obvykle bývají při loginu zapnuté nějaké statistiky/úvodní info a bez přístupu k disku přihlášená ssh sešna nenaběhne.

[krakenpico]

Zkoušel jsem dnes v rychlosti na live SystemRescue příkaz stress-ng -a 0 a za 10minut tam bylo 0 failed. Ještě zkusím s připojenými disky.

[Lu Kash]

Tak to jsem zvedavy, co to bude:) Memtest byl? Nechal bych bezet dmesg -w na pripojenem monitoru, pokud je v logu neco vic pred zamrznutim, bude to tam. Pres sit uz to treba neproleze.