Re: LXC občas podivně zatuhává síť/socket/služba

Pavel Kankovsky peak na argo.troja.mff.cuni.cz
Neděle Květen 7 13:41:09 CEST 2017


On Tue, 2 May 2017, Petr Stehlík wrote:

> Připomínám, že na hostiteli běží virtuál s poštou a několik dalších
> virtuálů s weby. Po nějakém čase se třeba na poštovním serveru
> "zasekne" nejčastěji Dovecot, obvykle těsně následovaný i SSH. Vypadá
> to tak, že se např. telnetem přihlásím na port 110, zadám "username
> pstehlik", myslím, že ještě stihnu zadat "pass tajne" a pak už dál nic,
> zůstane to tuhé. Podobně i ssh - připojím se, zeptá se mě na heslo
> (pokud se hlásím bez klíče), zadám heslo a dál už nic. Nejde ani Ctrl+C
> na přerušení mého ssh klienta. Až po několika minutách tam vytimeoutuje
> spojení.

Já bych řekl, že je tom vidět jistý vzor: totiž že se to zasekává během 
ověřování přihlašovacích údajů. To by mohl být problém obecně při práci 
s databází uživatelů, nebo při ověřování jejich hesel, nebo při zapisování 
do logu. Nebo možná v něčem úplně jiném.

To samozřejmě předpokládá, že Váš pocit, že se POP-3 sekne až po poslání 
hesla, je správný. Takové detaily jsou dost důležité a je docela přínosné 
to vědět přesně a s jistotou.

Kde se zasekne SSH při použití klíče? A s tím heslem se to zasekne 
až po ověření hesla nebo dřív? Zkusil jste ssh -v?

Víte aspoň, jak ty procesy visí? V jakém jsou stavu a co ps ukazuje ve 
sloupci WCHAN?

Jak vypadají logy? Ty zaseklé záznamy se nějak logují nebo ne? Objevují se 
v logu v době zaseknutí jiné záznamy?

> Tohle všechno by nebylo ještě tak zlé, kdyby se nákaza nerozšířila i na
> samotného hostitele, kde typicky postihne ssh. V tu chvíli se na něj
> nemůžu přihlásit, abych restartoval ten zaseklý poštovní virtuál a tak
> musím potupně jet do serverovny.

Poslední dobou bývá právě z těchto důvodů dobrým zvykem mít u serveru 
nějaké rozhraní na vzdálený management nezávislé na OS, ať už je to 
"IPMI", IP KVM nebo třeba sériák přes null modem na jiný stroj...

> Zajímavé taky je, že po opravě jednoho virtuálu restartem se do 24
> hodin "pokazí" druhý virtuál (web server), kde se typicky zasekne SSH a
> pár dalších služeb (nejčastěji cron, ale teď jsem tam třeba našel
> "mysqldump | gzip" dělající něco celé hodiny).

Hádám, že ani zde nevíte, na čem to bylo zaseklé.

> Konfigurace všech virtuálů je stejná, mimochodem...

To asi tak úplně není, když je na jednom poštovní server a na jiných 
weby a to, jak předpokládám, nejspíš různé.

> Co je neuvěřitelné je, že po přihlášení se na konzoli se samo od sebe 
> "spraví" to zablokované ssh na hostiteli. To jsem si ověřil teď v sobotu 
> a ještě jsem se s tím nesrovnal.

To je opravdu zajímavé.

> Připomínám, že když daná situace nastane, nemám čas na jakoukoliv
> analýzu, neboť jde o živý server hojně využívaný početnou klientelou.
> Minule mi někdo navrhoval gdb a zjišťovat, kde přesně to v ssh démonu
> stojí a na čem to čeká - tak to bohužel nemůžu, na to není čas.

Nevím, jak rychle reagujete na případné výpadky, ale nezdá se mi moc 
pravděpodobné, že by to bylo rychleji než v řádu minut.

Spustit ps l PID, strace -p PID a/nebo gdb PROGRAM PID a pak dát "bt" a 
"quit" zabere pár sekund a dokonce by to šlo i naskriptovat (pro to gdb 
může být vhodné si předem připravit ladící informace) a pravděpodobně by 
Vás to posunulo v řešení problému hodně dopředu a brzo se to vrátilo
ve formě zvýšené dostupnosti.

Možná by také stálo za pokus udělat repliku toho stroje a pokusit se 
problém replikovat na něm (i když je možné, že by to vyžadovalo nějakou 
umělou zátěž).

-- 
Pavel Kankovsky aka Peak                      "Que sçay-je?"


Další informace o konferenci Linux