[megoldva] Szerver megfagy, pingelni se lehet

Ubuntu Linux

Kedves mindeni,

értetlenül állok egy probléma előtt. Adott egy szerver, ssh, apache, postfix, miegymás és tegnap óta olyat csinál, hogy random időpontban olyannyira megfagy, hogy pingelni se lehet. Ennek ellenére az iptables szorgalmasan loggol a syslogba beérkező szemetet, tehát valami fut a szerveren. Ha összeszedte magát, akkor utána megint megy rendesen.

Egyik ismerősöm javaslatára föltettem az acct csomagot (Ubuntu Server fut rajta) és semmi érdemleges eredményt nem találtam azon kívül, hogy rettenetesen sok processz fut (bár ez lehet a daily cronjobok eredménye).

Az egyik, amire gyanakszom, az a clamav mert az eszi a legtöbb rendszererőforrást és találtam egy ilyen bejegyzést is:

clamd F clamav ?? 549.75 secs Sat Oct 27 15:17

Természetesen az sincs kizárva, hogy hardverhiba, de nem tudom, hogyan lehetne kideríteni.

Aki segít kideríteni, mi a baj, annak fáradozásait akár jutalmazni is tudom mivel ez a szerver nagyon fontos nekünk.

János

  • 2982 megtekintés

( yndy | 2007. 10. 28., v – 09:01 )

"rettenetesen sok processz fut(bár ez lehet a daily cronjobok eredménye)."
Nem tudod pontosan, hogy mik futnak?
Ha sok a process, akkor sok memoriat(cpu-t) hasznal, feltetelezem, hogy novekszik a load, ezekutan meg nem jut eroforras arra sem, hogy pong-oljon a szerencsetlen gep.
Szoval en azt javaslom, hogy deritsd ki, mi az a sok process.

Sajnos nem mert amikor a fagyás történik, akkor nem tudok kiadni ps aux parancsot és arra még nem jöttem rá, hogy tudom a szerveroldalról detektálni a fagyás.

Egyébként ilyenekre gondoltam:

bash F root ?? 0.00 secs Sun Oct 28 08:41
bash F root ?? 0.00 secs Sun Oct 28 08:41
bash F root ?? 0.00 secs Sun Oct 28 08:41
bash F root ?? 0.00 secs Sun Oct 28 08:41
bash F root ?? 0.00 secs Sun Oct 28 08:41
bash F root ?? 0.00 secs Sun Oct 28 08:41
bash F root ?? 0.00 secs Sun Oct 28 08:41
bash F root ?? 0.00 secs Sun Oct 28 08:41
bash F root ?? 0.00 secs Sun Oct 28 08:41
bash F root ?? 0.00 secs Sun Oct 28 08:41
dircolors root ?? 0.01 secs Sun Oct 28 08:41
bash F root ?? 0.00 secs Sun Oct 28 08:41
lesspipe root ?? 0.00 secs Sun Oct 28 08:41
lesspipe F root ?? 0.00 secs Sun Oct 28 08:41
dirname root ?? 0.00 secs Sun Oct 28 08:41
basename root ?? 0.00 secs Sun Oct 28 08:41
bash F root ?? 0.00 secs Sun Oct 28 08:41
groups root ?? 0.01 secs Sun Oct 28 08:41
id root ?? 0.00 secs Sun Oct 28 08:41
cons.saver S root ?? 0.00 secs Sun Oct 28 08:41

stb. Nyilván futnak shell scriptek, csak fogalmam sincs, hogy tudom kideríteni, melyik a bűnös. Pl van itt kb 15 gzip processz, futott 0.01-ig... passz.

En beallitanek egy scriptet, ami kb percenkent (vagy lehet surubben) kiad egy "ps aux" parancsot, es az eredmenyt betolja egy fajlba.
Ezenkivul a "top" eredmenyet is ugyanilyen suruseggel logolnam.
Meg egy "tcpdump"-ot is igenybe vennek, amivel a halozati forgalmat lehetne naplozni.

Ubuntu csomagból ami van és 32 bites a szerver. A 6-12 órás frissítést érdemes bekapcsolni egyébként, mert a clamavosok szerint a sűrűbb az gáz. Nekünk más szívásunk mégpedig az hogy konkrétan egy frissítés után picit megbolondult. :)

Na, asszem megvan a hiba oka. Idézet a syslogból:

Oct 28 11:57:05 pasztormuvek amavis[4940]: (04940-01) (!!) ClamAV-clamd av-scanner FAILED: Too many retries to talk to /var/run/clamav/clamd.ctl (Can't connect to UNIX socket /var/run/clamav/clamd.ctl: No such file or directory) at (eval 44) line 268.
Oct 28 11:57:05 pasztormuvek amavis[4940]: (04940-01) (!!) WARN: all primary virus scanners failed, considering backups

És utána jön a monit figyelmeztetés, hogy CPU load 99,2%.

Ezen elindulva, clamav logja:

Sun Oct 28 11:55:36 2007 -> Socket file removed.
Sun Oct 28 11:55:36 2007 -> Pid file removed.
Sun Oct 28 11:55:36 2007 -> --- Stopped at Sun Oct 28 11:55:36 2007

Végül a freshclam logja:

ClamAV update process started at Sun Oct 28 11:56:52 2007

Ergó, ha neki indul a freshclam és éppen akkor jön levél, 5 percre megfagy a szerver. Most már csak azt kell kitalálni, mit lehet ezzel csinálni.

Nem a freshclamot kell használni, hanem a clamav és clamav-data csomagokat a volatile repóból.

Ez megszabadít a freshclamtól. ugyanis készen "verzióhoz gyártva" tölti le a vírusadatbázisokat.

--------------

Nem a zsömle kicsi, a pofátok nagy...

Én inkább a freshclam-ot indítanám időzítve (ha yól emléxem, ez megtehető). Mondjuk éjjel 2 és 3 között, amikor nem jő (annyi) levél. Esetleg átmenetileg a postfix-et addig lelőni. Levélvesztés nem lesz, mert a küldő szerverek egy darabig türelmesen próbálkoznak a szervernél, és a freshclam gyorsan végez.

( borneoo v | 2007. 10. 28., v – 10:30 )

Ubi 7.04-el nekem is van hasonlo, neha fagyas, logban eddig semmit nem talaltam,... meg en is keresem az okot :(

( Replaced | 2007. 10. 28., v – 12:15 )

> Ubuntu Server

does not compute

--
Bow down and admit defeat. | Old, weak and obsolete.

( janoszen v | 2007. 10. 28., v – 22:43 )

Egyre rosszabb a helyzet. Lelőttem a clamavot, a tomcatet, gyakorlatilag mindent ami nem szükséges a működéshez, egyedül az Apache, a MySQL, a Postfix és az amavis marad és éppen most produkál egy király kis fagyást. Lehet hogy tényleg hardver lesz, viszont fogalmam sincs, hogy kellene kideríteni, micsoda.

memtest86 ?

"Ha összeszedte magát, akkor utána megint megy rendesen."
Tehat nem is fagyas.

lspci ?

Valami furcsa iptables szabaly ?

Gep kozeleben vagy amikor "lefagy" ? Helyileg sem tudsz parancsot adni ?

Egy ping rohadt egyszeru feladat. Network/IP valoszinuleg mukodokepes, ha az iptables tud meg logolni is.
FIXME, Talan megalithatja ip forgalmat ,ha az iptables logolasi uzeneteit nem veszi at logger. Ami szarmazhat disk tulterheltsegebol , i/o problemakbol.

vmstat ?

Milyen gyorsan kepes masolni a rendszer fileokat ? (pl. 2Gb -t)

memtest most megy.

lspci kidobja a gépben levő divájszokat, jónak is néz ki.

Sajnos nem vagyok a gép közelében, be tudnék menni csak nem tudom, mikor fagy le, tehát ott kéne dekkolnom egész nap.

IPtables: arno-iptables-firewall-t használom. Tudom, kész csomag, de mivel nem értek annyira az iptableshez inkább nem kisérleteztem.

vmstat

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 114460 325840 6892 92084 26 48 115 71 238 76 84 1 14 1

Túlterhelés? Egyáltalán nincs load a szerveren, a sok windowsos és próbálkozós gép szemetétől eltekintve.

lspci ugy ertetem, milyen hardware ez a cucc?

Mennyi ideig tart egy elerhetetlenseg ?

Ha kuldesz 10 levelet egyszerre, akkor elojon ?

#Protection against SYN-flooding (DoS attacks)
#Protection against ICMP-flooding (DoS attacks)

Nem lehet hogy tul erzekeny , es akkor is lelovi netet amikor nem kene ?
Vagy nem general tul nagy logfilet ?

00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2)
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev a2)
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:0a.0 FireWire (IEEE 1394): Texas Instruments TSB82AA2 IEEE-1394b Link Layer Controller (rev 01)
05:00.0 VGA compatible controller: ATI Technologies Inc RV410 [Radeon X700 Pro (PCIE)]
05:00.1 Display controller: ATI Technologies Inc RV410 [Radeon X700 Pro (PCIE)] Secondary

Gyk. egy erős PC némileg átalakítva. Elvileg a syn flood protection nincs túl alacsony értéken, az arno-iptables-firewall csomagot használom a központi Ubuntu repóból, szal valszeg már feltűnt volna valakinek ha nem működik.

Ami az előjövetelt illeti, teljesen random időpontokban tud előjönni, nem levél váltja ki (syslogból visszanéztem).

Esetleg még az merült föl, hogy a logokba íráskor jön elő ez. Sajnos a kernel minden egyes eldobott csomagot loggol, ami elég tetemes mennyiség.

"Sajnos a kernel minden egyes eldobott csomagot loggol, ami elég tetemes mennyiség."

akkor itt lesz a kutya elásva

egy ilyesmit próbálj meg beszúrni a logok elé / ba iptablesbe:
iptables -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -m limit --limit 5/min -j LOG --log-prefix "=== WARNING SYN/FIN scan ==="

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.
debian 4.0 - linux-2.6.22.10-pancs1-wifi2 - 2.6.22.9 kernel madwifivel itt

Megtörtént. Kivettem. Ennek ellenére nem vagyok boldog. Valahogy meg tudom oldani, hogy egy processz ne ehessen meg végtelen mennyiségű processzoridőt? Mondjuk úgy 70% környékén kényelmes lenne limitálni...

Szerk: gondolkodom azon, hogy mondjuk percenként lekérdezem a ps aux-ot és ami nagyobb 80%-nál, azt renice -1. Csinál már valaki ilyet?

Az egészet tedd bele pl. egy openvz-be. A többi virtualizációt nem igazán ismerem, openvz-nél futásidőben lehet pl. a virtuális gép max cpu foglalási idejét is szabályozni.
Náluk a tavasszal volt hasonló probléma egy P4 gép routolt, a pci hálókártyák túl sok megszakítást generáltak, az egyébként 0.1% körüli cpu terheltség ilyenkor 100%-ra ment fel amíg a kioctl dolgozott.

Mik

Ezt felejtsd el szerintem.
A processzoridőt nem % -ban mérjük, hanem rendes időben. Ezt lehet limitálni, bár akkor a kernel kilövi azt a processzt, ami ezt túl lépi és ez így elég gázos lenne számodra.
Ötlet: ha az init scriptjét módosítanád úgy, hogy kisebb nice levellel induljon?

--
http://laszlo.co.hu/

Én inkább a /etc/security/limits.conf környékén néznék körül. A nyitott processzek száma korlátolható.

A processzoridőt valóban nem százalékban mérik, hiszen mint a neve is mutatja idő.

Én a helyedben behatóbban tanulmámyoznám a konfigjaim, és a tűzfalam, mert azok lehetnek hibásak (igen, még a tűzfal is). A konfigokban például az egyszerre kezelt kapcsolatok számát limitálnám, a tűzfalra sajnos annak ismeretének hiányában nincs tippem.

Attól hogy renice-lsz, az csak egy workaround, magát a problémát kellene megszüntetni. Arról nem is beszélve, hogy a scripted is processzort eszik, és lehet, hogy el sem jutsz a renice sorig, mert olyan hirtelen megugrik a load.

Nekem pont hasonlo geppel volt gond. Kiderult hogy annal a szervernel is az alaplapi halokari kezdett rohadni (idonkent akadozott es fagyott, majd ujra jo lett egy darabig). Ment a gepbe egy rendes halokartya, a problema azonnal megszunt.
Ja es en a biosban minden felesleges cuccot letiltanek (hangkartya, firewire, soros port, stb...)

( budacsik | 2007. 10. 29., h – 10:04 )

Nekem is volt pontosan ilyen problémám, most eszembe jutott.
Az alaplapi hálókari volt a ludas szintén, elég sok error-t mutatott az ifconfig, majd egy új hálókari be, és megy azóta is egészen múlthétig.
Megint lefagy "szó" nélkül. Logot nem találok, semmi hiba. ifconfigban sem látok error-t. Hihetetlen, hogy semmi log nem keletkezik a hibáról. Ezt ma reggel megismétele.

Ötlet még:
#vmstat 2 > vmstat.log

Ez futtasd a következő fagyiig, majd nézd meg mikor elhasalt, mit látsz benne.
Párhuzamosan iostat 2 > iostat.log is mehet.
A vmstat logjában nézd a cs oszlopot (content switch), ha ez túl magas, az lehet probléma.

--
http://laszlo.co.hu/

Vagy nézd meg pl. a mii-tool -al a hálókártyád paramétereit.
Javasolt az autonegotiation kikapcsolni és fixen megadni a megfelelő sebességet és duplex módot.
E miatt már szívtam én is jó sokat. Igaz nem linux alatt, hanem Solaris alatt és nem fagyott csak iszony lassú lett a hálózati átviteli sebesség. Valahogy a Cisco switch -el nem kommunikálta le jól a kapcsolódás sebességét.

--
http://laszlo.co.hu/

( janoszen v | 2007. 10. 31., sze – 17:08 )

Nos, jártam bent a szerverközpontban és megoldódott a probléma. Olyasmi, amire soha nem számítottam volna.

A gépházat kinyitva a Sapphire Radeon X700Pro hűtőventillátorának a forgó része a gépház aljában volt, a motor teljesen szétrohadva, elferdülve a kártyán.

Ergó, amikor a vidkártyának melege lett, kezdett random módon instabil lenni. Innentől kezdve egyszerű volt, rohanás a sarki sztech boldba, új (passzív hűtéses) vidkártya, vissza, beszerel, kész.

Ergó, a napom került vagy 20k-ba. Vettem egy új tápot, új hálókártyás előre és miután kiderült mi a hiba, még egy új vidkártyát is. Soha többet nem veszek PC alapon szervert.

Üzleti döntések... át akartunk hozni egy pár domaint és nem szerettünk volna már tárhelyért külön fizetni, ha már úgyis saját szerver lesz, úgyhogy szerver be, DNS föl, átreg megy. A hardverrel való szívás így is, úgy is meglett volna, csak lehet hogy nem ilyen körülmények között.

( janoszen v | 2007. 11. 01., cs – 10:29 )

Na, lehet hogy mégsem oldódott meg. Hiába cseréltem ki benne az említett alkatrészeket, ugyanúgy megfagy. Az az érdekes, hogy most élő tanuja voltam, amikor rádugták az IP terminált (klavi, egér, monitor) akkor hirtelen föléledt a gép és amíg rajta van, addig az égegyadta világon semmi baj nincs vele. Találkozott már valaki ilyesmivel?

Na, úgy néz ki nem a konzol függvénye, most volt egy fagyás és az IW-sek azt mondták, hogy loginon áll a gép, ami semmiképpen nem jó, mert akkor nem indultak a szolgáltatások, amiknek el kell indulniuk.

Szerk: elkaptam fagyott állapotban IP konzolon. Állapot a következő:

- Tudom pingelni a gatewayt és azon kívül semmit.
- Minden más szabályszerűen működik.
- /etc/init.d/networking restart megoldja a problémát.

Ezek pedig feltételezések:
- A fagyás kb 24 óránként lép föl szabályszerűen.
- Azóta van, amióta másik switch van a gép előtt.

Nem az Interware hibája, külső céggel vagyok ott és azoknak saját switchük van. Elvileg valami ultramodern márkás dolog, a régi meg GagyiWare, mégis az utóbbi jegyezte meg jobban. Az is valószínű, hogy csak alacsony forgalmú gépeknél fordul elő, hiszen - lévén tesztstádium - gyakorlatilag van, amikor órákig egy bit se mozog a madzagon.

Mindegy, script megvan plusz bónuszba ha nem éri el a pingetésre megadott hostokat, akkor csinál egy hálózat újraindítást. Ha kell valakinek, szóljon.

Durván annyi, hogy csinálasz egy scriptet, ami pingel hostokat, az eredmény egy fájlba írja, aztán ezt a filet megszűröd grep-pel a "Destination Host Unreachable", "Network Unreachable", vagy inerzen a "bytes from" kulcsszavakkal, ha az eredmény nem 5,10,20, stb. sor, akkor /etc/init.d/network restart.
Mindezt cronba rakod, tetszőleges időközönként meghívod (3, 5 perc).
--
Discover It - Have a lot of fun!