Habár szerintem már nincs olyan Exchange-közeli ember, aki ne hallott volna az elbökött bevezetése miatt felettébb rossz hírnévre szert tett back-pressure folyamatról, de még mindig van hús a csonton, melyet le lehet rágni.
Ügyfél. Exchange 2007, délután fejreáll. Szaki elkezd nyomozni, megállapítja, hogy elfogyott a C:-n a hely (hiába, hol legyen az smtp queue), elkezdi átrakni a D:-re, de aztán gyorsan el kell mennie máshová, telefon nekem, hogy fejezzem be. Az ilyen hívásokban benne van minden, amiért öröm élni: ideges ügyfél, fejreállt levelezés és egy más ember által elkezdett, de aztán félbehagyott megoldási folyamat.
Szerencsére a probléma tényleg egyértelmű volt: világosan ott figyelt a logban, hogy a queue log-ra kalkulált hely elfogyott, azaz a pánikindikátor 97%-on állt, és ekkor az Exchange már lelövi a levelezést.
Emlékszem, anno mennyit anyáztuk ezért az Exchange fejlesztőket, pedig alapvetően igazuk van. Úgy döntöttek, hogy az adatbázisok – és a 2007-estől már a queue is adatbázis – konzisztens állapota fontosabb, mint a szolgáltatás megléte, azaz ha már borzasztóan kevés a hely, akkor elindítanak egy clean shutdown-t, még mielőtt az elfogyott hely miatt dirty shutdown következne be. Viszont az anyázás is jogos volt, ugyanis az első verzióban a kevés hely az 5GB-re volt belőve. Persze, hogy nem értette az egyszeri admin, hogy most mi a fasz baj van, amikor a 10 GB-s diszk fele még szabad? Cifrázta a helyzetet, hogy nem esett le, sőt, a tapasztalataim szerint még ma sem esett le sokaknak, hogy a queue is adatbázis, tehát bőven hagyni kell neki helyet. És legfőképpen nem a meglehetősen elhanyagolt C: partíción tárolni.
No, mindegy, a kollégától megtudtam, hogy elindított egy szkriptet, mely átmozgatja a queue-t a D: meghajtóra, a folyamat le is ment, de valami még nem kerek, mert továbbra sem indul a el Transport service. Ekkor tovább szürkült a tekintetem. Valahogy nem szeretem, ha az ilyen kényes lépéseket szkriptből futtatjuk, különösen akkor nem, ha maga a mozgatás nem bonyolult és ráadásul jól dokumentált is. Így kezdhettem azzal, hogy leellenőriztem a szkriptet.
Ránézésre minden rendben. Jogosultságok beállítva, ahogy kell, az edgetransport.exe.config fájlban is korrektek a queue bejegyzései. A Transport service pedig elindult, majd pár másodperc múlva megállt.
Hmm.
Eventlog. Azt írja, hogy valami process fogja a queue adatbázist, az Exchange nem fér hozzá.
Vírusirtó. Tuti. A rohadt anyját. Megnéztem és így legyen lottó ötösöm. Valós idejű fájlvédelem bekapcsolva, a kivételek között nem szerepelt az új queue könyvtára. Felvettem. Erre az antivírus program közölte, hogy ehhez újra kellene indítani a gépet.
Hívtam a helyi embert.
– Te, újra kellene indítani az Exchange szervert. Gondolom, nem probléma, mert úgysem megy a levelezés.
– Ööö, ez nem Exchange szerver, hanem SBS. Ezen megy a cég mindene.
– Oké, értem. Újraindítható?
– Nem igazán.
– Tőlem. De addig nem lesz levelezés.
– Khm. Megkérdezem az ügyfelet.
Hamarosan jött a telefon.
– Újraindítható. Akár többször is.
Gondolom, mindenkit hazazavartak, hogy mára vége a munkaidőnek. Szeretem az ilyen rugalmasságot.
Restart. Transport service? Megint áll. Nofene, nofene. Eventlog. Ugyanaz. Valami fogja az adatbázist.
Itt hirtelen elfogytak az ötleteim. Oké, ismerem a Process Explorert, de általában csak a legvégső esetben használom. Kell itt még lennie kézzelfogható magyarázatnak.
Böngésztem tovább az eventlogot és hoppá! Nem csak egy hibaszál van, hanem kettő. Az egyik ez a ‘valami fogja a queue-t’, de van egy másik is, mely nem a szolgáltatás indításakor keletkezik, hanem rendszeres időközönként. Hogy mit mond? Hát, ez elég fura. Az a baja, hogy nem tudja meghatározni a D: meghajtóra jellemző minimális allokációs egység értékét. (Vagy valami hasonló. Nem írtam fel, meg egyébként is, magyar nyelvű szerver.)
Még csak nem is hallottam hasonlóról, de elméletileg okozhatja ez is a bajt. Gugli. Nem mondanám, hogy túl sok találatot kaptam, de ugye az ideális keresés az, amikor csak egy találat van, de az pont az, ami kell. És volt is egy elgondolkodtató cikk: azt írta a hapi, hogy ahhoz, hogy az Exchange 2007 adatbázist tudjon üzemeltetni egy meghajtón, a Network Service számára FC jogot kell adni a gyökérkönyvtáron. Csak. Megnéztem. Nem volt. Hjaj. Megadtam.
Persze, hogy elböktem. Nem mentem be az Advanced gomb mögé, hanem csak nyomtam egy OK-t. Erre elkezdte hozzáadni a Network Service-t a D: meghajtó összes objektumához. Vártam 5 percet. Aztán kimentem konyhába, megvacsoráztam. Fél óra. Visszajöttem. Még nem fejezte be. Na, ja: SBS, azaz fájlszerver is. Aztán lelőttem: mivel ez addicionális jogadás, így nem lesz belőle senkinek sem baja, ha a fájlok felénél nem lesz benne a Network Service a listában. Különben is, ha elindul az Exchange, akkor rendezem a jogosultságokat.
A lényeg: a gyökér most már jó. Transport Service restart… aztán pár másodperc múlva megállt.
Ilyen nincs.
Aki rendszeresen hárít el incidenseket, tudja, milyen érzés ez. Amikor sokadjára állítasz fel valamilyen hipotézist – egyik zseniálisabb, mint a másik – aztán feltúrod az internetet, hogyan lehet a feltételezett akadályt eltakarítani, majd valahogy el is takarítod, aztán hátradőlsz… és nem, az incidens nem szűnik meg.
A végén tényleg használnom kell a Process Explorer-t.
Aztán eszembe jutott még valami. Az a nyűves antivírus szoftver. Nem lehet, hogy az nem engedi elérni a D: gyökeret? Most már nem finomkodtam, kikapcsoltam a realtime fájlvédelmet. Service restart… és… és még megy… még mindig megy… nocsak, még mindig… eventlog… semmi. Ez megjavult.
Hátradőlés. Huh.
Aztán a következő kérdés: hogyan tovább? Mondjam azt az ügyfélnek, hogy ne használjon fájlszintű vírusvédelmet? Egy fájlszerveren? Háát, izé. Akkor inkább próbáljuk meg a két rendszert összenutolni, hátha elketyegnek egymás mellett. Drasztikus kísérlet #1: visszaindítottam a realtime védelmet. A Transport service meg se rezdült. Jó jel. Drasztikus kisérlet #2: bekapcsolt realtime védelem mellett újraindítottam a Transport szolgáltatást. Elindult. Sőt. nem is állt le. Még jobb jel. Tehát elég volt meghatároznia azt az allokációs egységet egyszer, utána már nem piszkálja a gyökeret. Drasztikus kisérlet #3: szerver újraindít. Transport service ugyanúgy megy. Tehát a meghatározott értéket nem a memóriában tárolta, hanem ki is írta valahová.
Oké. Case solved.
Tanulság?
Van az Exchange adminok egyes számú posztulátuma:
“Mindig a víruskereső a hibás.”
Nos, ezt meg kell változtatni a következő formulára:
“Mindig a víruskereső a hibás, még akkor is, ha látszólag ártatlan.”
Recent Comments