Hoi
we zien vreemd gedrag, als we uitvoeren shell script is het succesvol uitvoeren maar het is nog steeds PID opknoping als we zien ps-ef | grep script1.ksh totdat we doen Kill <PID>


$ script1.ksh
$
$ Ps-ef | grep script1.ksh
user1 249996 1 0 10:48:40 ptn / 1 0:00 / usr / bin / ksh script1.ksh

Inside script gebruiken we
afrit opdracht voor de voltooiing van het script



OS: AIX 5.3.0.0

Kan iemand adviseren

Laat me weten als u nog aanvullende informatie.


bedankt
SmithK

Moeilijk te zeggen als u niet de code van het script.

Ik heb beperkt de kwestie die wij gebruiken gzip in het script .. om het bestand te comprimeren .. we schrijven aan de pijp dan zullen wij met behulp van gzip compreess
hieronder is de voorbeeldcode

#! / usr / bin / ksh

/ usr / sbin / mknod NAMEDPIPE p

gzip -1 <NAMEDPIPE> Export &
db2 "uitvoer naar NAMEDPIPE van del SELECT * FROM test" # # db2 commando aan
# # Export gegevens
rm-f NAMEDPIPE


Na voltooiing van het script, met succes, ik zie nog steeds het script PID, zie ik niet in verband enige verbinding met DB, Eigenlijk script opknoping daar niets doen, ik vermoed gzip -1 <NAMEDPIPE> Export & termenating niet ... . voldoende

Bedankt
Smithk

In uw script u een achtergrond proces dat wordt gelezen van de named pipe (gzip).

Volgende u een proces (db), die schrijft voor de named pipe.

Zodra het schrijfproces (DB) wordt gedaan u de named pipe.

Meest waarschijnlijk op dat moment de lezing proces (gzip) nog niet volledig lezen van alle gegevens van de named pipe.

Sinds de named pipe (en de gegevens in de IT) is verwijderd van de lezing zal nooit een EOF.

In principe moeten de lezing is nog een open file descriptor die verwijst naar iets dat bestaat niet meer.

Daarom is de gzip commando niet zal beëindigen.

Aangezien dit proces is een kind van je script, je script niet zal beëindigen.

Het lijkt alsof het beëindigd, alles in het werk deden was de terugkeer van controle terug naar uw schelp. Onder het waitingfor dood van een kind.

Na het uitvoeren van je script, ik verwacht dat u niet alleen kunnen vinden je script met ps in de tabel, maar de gzip ook.

Bovendien, ik begrijp waarom u gebruik maken van een named pipe voor iets als dit.

Zou het niet veel makkelijker te gebruiken:

db2 "uitvoer op de uitvoer van del SELECT * FROM test"
gzip -1 UITVOER

Ik ben niet bekend met het db commando, maar ik neem aan
db2 "SELECT * FROM test"
zou de output naar je scherm.

Zo ja, waarom niet gebruik maken van een "anonieme" pijp:
db2 "SELECT * FROM test" | gzip -1 -> EXPORT.gz

Het kan werken met een named pipe en indien u de 2 commando's:
:
#! / usr / bin / ksh

/ usr / sbin / mknod NAMEDPIPE p

db2 "uitvoer naar NAMEDPIPE van del SELECT * FROM test" & # # DB2 commando
# # Export gegevens
gzip -1 <NAMEDPIPE> EXPORT.gz

rm-f NAMEDPIPE

Ik denk ja
gzip -1 <NAMEDPIPE_FILE> EXPORT_FILE &

oorzaak van het probleem, we zijn schriftelijke instructies aan de pijp, omdat we niet genoeg ruimte op bestandssysteem te exporteren gegevens, wij schrijven naar Pipe comprimeren en vervolgens op de achtergrond.

we kunnen het niet als dit
db2 "uitvoer naar NAMEDPIPE van del SELECT * FROM test" &
gzip -1 <NAMEDPIPE> EXPORT.gz

Sinds wanneer hebben we een fout op de exportmarkten, zoals tabel niet gevonden ... volgende stap gzip is waitting voor de PIPEFILE, en het script zelf is opknoping zonder over te gaan tot de volgende stap.


Elke inzicht?

bedankt
smithk

Je zou kunnen proberen om de bouw van een vertraging voor het verwijderen van de pijp.

slapen 30
rm-f NAMEDPIPE