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

Odpovím stručně proti netiketě nahoře, u 14 měsíců starého "vlákna" to
snad bude pochopitelné:

pane Kaňkovský, děkuji za Váš mail, který mě (díky strace a gdb)
nakonec přivedl k tomu, že se sshd a CRON procesy náhodně jednou za pár
týdnů/měsíců zasekávaly na zápisu do syslogu. Pravděpodobným viníkem
byl syslogd z debian balíčku inetutils-syslog, protože na jiných
virtuálech používám rsyslog a tam podobné výtuhy nenastávají.

Teď jsem nainstaloval rsyslog i na tento poslední zlobící server a
předpokládám/doufám, že jsem to tímto vyřešil.

Připomínám pro historii, že jsem mnoho let k paravirtualizaci (dnes by
se řeklo kontejnerizaci) spokojeně používal linux-vserver, ale pak jsem
musel přejít na LXC a s tím začaly níže popsané občasné výtuhy, které
tedy zřejmě nějak souvisely či byly způsobeny jedním konkrétním
syslogem (nebo možná nějakým nastavením okolo něj, zděděným z předchozí
virtualizace).

Čisté (from scratch) instalace serverů pod LXC nikdy nezlobily, takže
to skutečně nějak souviselo s přenosem původních virtual guestů z
linux-vserver do LXC.

Třeba to někomu pomůže, nebo spíš by pomohlo, kdybych na to přišel tak
před 3-5 lety :-)

Petr


Pavel Kankovsky píše v Ne 07. 05. 2017 v 13:41 +0200:
> 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?"
> _______________________________________________
> Linux mailing list
> [email protected]
> http://www.linux.cz/mailman/listinfo/linux
_______________________________________________
Linux mailing list
[email protected]
http://www.linux.cz/mailman/listinfo/linux