Hibakeresés háttérfolyamatokban és távoli munkamenetekben

PowerShell 5.0-nál korábbi verziók esetében nem volt könnyű dolgunk háttérfolyamatként futó vagy távoli módon futtatott szkriptek hibafelderítésében. Az általános módszer az volt, hogy a háttérben vagy távol futó szkripteket előtérben futtattuk, és ott használtuk a megszakítási pontokat és egyébb lehetőségeket. Ez akkor volt problematikus, amikor pont a paraméterátadással vagy az eredmények átvételével kapcsolatban gyanakodtunk hibákra, hiszen a normál módon futtatott szkriptekkel az így előforduló hibalehetőségek nem voltak szimulálhatók.

PowerShell 5.0-ban már teljesértékű módon, akár az ISE grafikus szerkesztőben is könnyen kereshetjük a hibákat.

Hibakeresés háttérfolyamatokban

Háttérfolyamatok esetében nagyon egyszerű a dolgunk. Nézzünk egy nagyon egyszerű példát:

Látható, hogy itt megszakítási pont helyett a Wait-Debugger cmdlettel szakítom meg a futtatást. Ha ezt elindítom, majd lekérdezem a futó háttérfolyamatokat, akkor ezt látom:

Egy új státus jelent meg, az „AtBreakpoint”, ami azt mutatja, hogy az adott háttérfolyamat a hibakeresésre vár. Ezt indítani a Debug-Job  cmdlettel tudjuk:

 És innentől használhatjuk a továbblépés, folytatás és egyéb lehetőségeket. Még látványosabb a dolog, ha a héttérfolyamat szkrtiptblokkját elmentjük fájlként, és azt futtatjuk háttérfolyamatként:

Itt szintén megáll a futtatás és szintén el kell indítani a debugger-t:

 De ilyenkor automtikusan betöltődik az elmentett szkript az ISE-ben egy újabb fülön és megjelenik a sárga héttérrel kiemelt sor:

100 . ábra Elmentett szkript háttérben futtatásakor teljes értékű a hibakeresés

Azért még mindig lehetne fokozni a hibakeresési élményt azzal, hogy az előtérben történő lépésenkénti végrehajtásnál át tudnánk lépni a Start-Job sorából a háttérben futó szkript lépésenkénti végrehajtásába, de ez sajnos még nem megy, muszáj Wait-Debugger-t tenni oda.

Az előző fejezetben látott „BreakAll” funkciót szintén ellátja a Debug-Job cmdlet. Ha a háttérfolyamatunk hosszabb ideig fut és nem raktunk be Wait-Debugger-t, akkor a Debug-Job erőszakkal is megállítja a háttérfolyamatot és belép hibekeresési módba.

Távoli munkamenetek hibafelderítése

Csak egy kicsit bonyolultabb a helyzetünk távoli munkamenetek hibakeresésekor. Induljunk ki hasonló helyzetből, mint az előzőekben látott, elmentett szkript-alapú példa volt, méghozzá tervezett hibafelderítést végzünk a Wait-Debugger cmdlet használatával:

Itt az $rs változóban tárolom a távoli futtatásra szánt szkriptet. Ennek első sorában található a $pid változó kiíratása, mert ez adja meg nekünk a távoli PowerShell processz azonosítóját és erre szükségünk lenne abban az esetben, ha nem rendelkeznénk a hibafelderítéshez szükséges sessionID-val. Ilyen példánk lesz a 2., ezt tehát mindenképpen érdemes valamilyen módon kinyerni a futtatás során.

Ezt a szkriptet elmentem az ideiglenes mappába, majd megnyitok egy kapcsolatot a távoli géphez. A szkriptet – kihasználva a PowerShell 5.0 új lehetőségét – ezen a távoli kapcsolaton keresztül másolom át a DC2016 gépem c:\powershell mappájába. Végén meghívom távoli végrehajtással ezt a szkriptet.

Láthatjuk, hogy a processzazonosító 3228 és hogy a távoli kapcsolat bontódott is, mert a távoli szkript hibakereső állapotba került. A session egyedi azonosítója (instanceID) látható is a figyelmeztető üzenetben, erre is szükségünk lehet.

Most tulajdonképpen bármelyik gépről folytathatjuk a hibafelderítést, egyszerűség kedvéért folytassuk ugyanazon a gépen, annál is inkább, hiszen a session objektum még mindig megtalálható a $s változóban, így egyszerűen újra tudunk ehhez csatlakozni, majd be is léphetünk ebbe a munkamenetbe:

Ilyenkor az ISE a PowerShell 5.0-ban – miután egy elmentett szkriptről van szó – meg is nyitja ezt egy új szkriptszerkesztő fülön:

101 . ábra A távoli szkript automatikusan megnyílik az ISE szerkesztőjében

Látható a fül szövegében, hogy ez egy távoli szkript ([Remote File]), de ettől függetlenül a hibafelderítés minden lehetősége rendelkezésünkre áll, mint például a lépésenkénti végrehajtás, vagy a változók tartalmának kiolvasása.

Most nézzük azt az esetet, amikor egy hosszan futó szkriptünk van, és nem tervezett módon akarunk hibafelderítést végezni. Ehhez a módosított szkript a következő:

Az első sorban a futó processz azonosítóját, a végetelen ciklusban az aktuális időt írom ki. Itt is elmentem a szkriptet és a távoli kapcsolaton keresztül másolom át a DC2016 nevű gépemre.

Ha ezt elindítom, meg is kapom a processz azonosítót és az időadatok elkezdenek csordogálni:

Nézzük most azt a helyzetet, mintha nem férnénk hozzá a session azonosítójához. Ez némileg igaz is, hiszen fut a szkriptünk így most nem tudunk belenézni a $s tartalmába, és nem akarjuk megállítani. Nyitok egy új Powershell Tab-ot az ISE-ben:

102 . ábra New PowerShell Tab - új PowerShell processz ugyanabban az ISE ablakban

És itt futtatom a következő cmdleteket:

Első lépésben tahát csatlakoztam a DC2016 gépemhez, majd az előbb látott 3176-os processzhez csatlakozom az új Enter-PSHostProcess  cmdlettel. Látható, hogy a sor elején, a promptban a [dc2016] mellett immár a [Process:3176] is megjelent. Még nem értünk teljesen célt, hiszen a processz egy új futtatási könyezetébe (másik szál) érkeztünk, a hibakeresést az 1-es számú Runspace-ben kell végezzük, így oda csatlakozom a Debug-Runspace  1 cmdlettel. Ilyenkor megint megnyílik a szkriptszerkesztőben a távoli szkript és sárga kiemeléssel mutatja, hogy éppen melyik sornál állítottuk meg a futtatást.

Ha végeztem a hibafelderítéssel és szeretném, hogy a szkript futása folytatódjon, akkor az új detach  paranccsal bezárhatom ezt az üzemmódot, majd exit-el kiléphetek a távoli kapcsolatból:

Word To HTML Converter