Variabele voor het PID van het vorige process

[Liegebeest]

Goeiemorgen

Ik ben op het moment bezig met een monitoring script voor Tivoli, wat na moet gaan of bepaalde queues e.d. van een stuk software correct functioneren. Het grootste deel van deze tests word uitgevoerd mbv een tooltje genaamd "runmqsc" en dit tooltje word dus ook regelmatig gerund (elke twee minuten worden er zo'n 20 instances van gerund).

Een van de tekenen dat een queue niet goed functioneert is wanneer zo'n "runmqsc" progje blijft hangen En nu moet ik dus in het script een nette check inbouwen die controleert of na een bepaalde tijd het process netjes is afgesloten.

De code die ik tot nu toe heb ik eigenlijk rete-simpel (vraag me ook af waarom die collega van me hierbij hulp nodig had), maar ik kwam er net via een collega achter dat dit niet goed gaat werken... Wat ik nu heb?

code:

detail=`runmqsc $QM<<EOF
             DISPLAY QLOCAL(SYSTEM.CLUSTER.TRANSMIT.QUEUE) CURDEPTH
             DISPLAY QLOCAL(SYSTEM.CLUSTER.TRANSMIT.QUEUE) MAXDEPTH
             END&
             EOF`
sleep 10
pgrep runmqsc >/dev/null 2>&1
if [ $? = 0 ]; then
             echo "Still running"
fi

Ziet er op zich uit alsof het gaat werken, niet waar? Dat zou het ook, ware het niet dat (en hier komt mijn denkfout) er niet een, maar meerdere runmqsc's tegelijk kunnen runnen... Er loopt namelijk nog een tweede script parallel aan deze en die roept ook runmqsc's aan

Aniway... Om dit lange verhaal nu met een korte vraag af te sluiten

Wat is een simpele manier om in de Korne Shell (ksh) te komen achter het PID van het laatst gerunde process??

$$ is de PID van de shell
$? is de exit code van het laatst gerunde process
$! is de PID van het laatst gerunde background process (en die is vreemd genoeg ook niet te gebruiken hier, ondanks de ampersand aan het einde van het commando)...

[Liegebeest]

Met hulp van een toevallig passerende collega heb ik het antwoord gekregen...

code:

detail=$(runmqsc $1 <<EOF
        DISPLAY QLOCAL($2) MAXDEPTH
        END &
        EOF)
sleep 10
jobs | grep runmqsc
if [ $? = 0 ]; then
        eval echo "\#--- MQM 009 --- ERROR $1 - $2 QUEUE NOT RESPONDING PROPERLY " >> $MSGFILE
        STATUS=NOK
fi

De boel kan dus op slot en bewaard worden voor het nageslacht...

[Verwijderd]

Je geeft runmqsc het commando
DISPLAY QLOCAL($2) MAXDEPTH
END &

Volgens mij hoort die & daar niet. Mogelijk negeert runmqsc hem, maar daar zou ik niet op willen rekenen.

Ik heb ook nog nooit meegemaakt dat runmqsc bleef hangen, dus misschien komt dat toch door een verkeerde script constructie.

[Liegebeest]

Je geeft runmqsc het commando
DISPLAY QLOCAL($2) MAXDEPTH
END &

Tja... In principe betekend

code:

runmqsc $1 <<EOF
        DISPLAY QLOCAL($2) MAXDEPTH
        END &
        EOF

Het zelfde als

code:

runmqsc $1 DISPLAY QLOCAL($2) MAXDEPTH END &

Die ampersand (&) geeft aan dat het process in de background moet runnen (zodat hij tegelijkertijd die sleep uit kan voeren voor de timeout)... Hij word dus niet aan runmqsc meegegeven, maar aan Solaris

Aniway... Mag ik aannemen dat je zelf ook met een MQ Series omgeving werkt? Dat zou wel erg grappig zijn! Je werkt toch niet toevallig ook bij de ING, heh?

Oh! En de reden dat bij ons runmqsc wel eens bleef hangen is het feit dat onze Veritas VCS cluster tot voorkort niet altijd even lekker liep... Daardoor bleef van tijd tot tijd de boel een beetje hangen en had het een schopje nodig...

EDIT:
codeblokken toegevoegd...

[Verwijderd]

cailin_coilleach schreef op 27 augustus 2002 @ 07:57:
[...]

Die ampersand (&) geeft aan dat het process in de background moet runnen (zodat hij tegelijkertijd die sleep uit kan voeren voor de timeout)... Hij word dus niet aan runmqsc meegegeven, maar aan Solaris

Ik wist niet dat een & binnen een HERE document toch door de shell geinterpreteerd wordt als "doe maar in de achtergrond". Ik zal het vanmiddag eens proberen, want eerder geloof ik het natuurlijk niet

Aniway... Mag ik aannemen dat je zelf ook met een MQ Series omgeving werkt? Dat zou wel erg grappig zijn! Je werkt toch niet toevallig ook bij de ING, heh?

Wel in een MQSeries omgeving, niet bij ING.

Oh! En de reden dat bij ons runmqsc wel eens bleef hangen is het feit dat onze Veritas VCS cluster tot voorkort niet altijd even lekker liep... Daardoor bleef van tijd tot tijd de boel een beetje hangen en had het een schopje nodig...

Ok, daar heb ik geen ervaring mee.

[Liegebeest]

Ik wist niet dat een & binnen een HERE document toch door de shell geinterpreteerd wordt als "doe maar in de achtergrond". Ik zal het vanmiddag eens proberen, want eerder geloof ik het natuurlijk niet

Of misschien heb ik gewoon heel erg geluk, want ik weet niet eens wat een HERE document is Ik freubel alleen aan het systeem voor de MQ jongens... Zij kennen de app en ik niet

Wel in een MQSeries omgeving, niet bij ING.

Ach ja... was vergeten dat er ook zat andere grote clubs zijn die het gebruiken... Als ik zo eens na denk dacht ik dat Albert Heijn het ook gebruikt

Ok, daar heb ik geen ervaring mee.

*grijns* wij ook niet echt, maar we doen ons best!

[Liegebeest]

Dude! Jij r0ckt
Je had helemaal gelijk wat betreft die ampersand... *lol* wat een n00bie fout eigenlijk... die ampersand hoorde _achter_ de EOF, niet er voor!

[Verwijderd]

Yep ik heb het vanmiddag geprobeerd, en je merkt niet dat het eigenlijk fout is omdat runmqsc ondanks dat hij het END commando niet accepteert wel gewoon stopt. runmqsc stopt namelijk automatisch als de commandos van stdin komen er een end-of-file binnen komt. De variabele waar je de output in opvangt zal onder andere een foutmelding over het END commando bevatten.

Kan overigens ook zo: echo "DISPLAY QLOCAL($2) MAXDEPTH"|runmqsc $1

Anyway, als je het commando in de background doet zul je de uitvoer niet in een variabele kunnen opvangen. Dat lukt wel als je de uitvoer naar een file re-direct. Dus zoiets:

TMPFILE=/tmp/mq.tmp.$$
runmqsc QueueManager > $TMPFILE 2>&1 <<EINDE
MQ commandos hier
EINDE &

RUNMQSC_PID=$!

sleep 10

# nu checken of process $RUNMQSC_PID nog loopt, en zo niet de output in $TMPFILE parsen.

[Liegebeest]

Een dergelijke constructie had ik inderdaad ook al in elkaar gebakken
Wat dat betreft zaten we op de zelfde lijn...

Helaas is een van de twee scripts een zootje van geneste if's en for's, dus dat moet ik eerst maar eens zien te ontwarren

[Verwijderd]

Ik heb heeel lang geleden ook met MQSeries gewerkt (HP-UX -> AS/400), en daar had ik van IBM een C-Programmaatje gekregen welke channels en queues kan controleren of deze nog up waren en wat de vullingsgraad e.d. was.

Misschien als je contact opneemt met IBM kunnen ze de source hiervan voor jullie beschikbaar maken? Het was geschreven door een engineer die ons toendertijd bijstond.

Voordeel van dit proggie was dat het een stuk minder resources vrat dan dat je met runmqsc hebt.

[Liegebeest]

Hmmzz.... Klinkt interessant us1111
Ik geloof zelfs dat we die code wel ergens rond hebben slingeren... Zou alleen niet weten waarom we het niet gebruiken... Ik ben, zoals al eerder is gezegd, niet zo thuis in MQ en houd me meer bezig met het beheer van de UNIX (solaris) boxen zelf...

EDIT:
Enige navraag leert mij dat men terdege bewust is dat die programmaatjes bestaan en dat men zelfs bezig is met het testen van die code... We zijn zelfs zover dat het in principe zouden kunnen implementeren, maar politiek geneuzel houd dat tegen

In principe zijn we ook tevreden met de code die we nu zelf hebben gebakken, dus dat zit uiteindelijk wel weer goed...

In elk geval bedankt allebei