Hej
vi ser konstiga beteende när vi kör shell script det är framgångsrikt genomföra men det är PID fortfarande hängande när vi ser ps-ef | grep script1.ksh tills vi Kill <PID>


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

Inuti script vi använder
exit kommandot innan färdigställandet av manus



OS: AIX 5.3.0.0

Kan någon ge råd

Låt mig veta om du behöver ytterligare information.


tack
SmithK

Svårt att säga om du inte med koden i skriptet.

Jag har minskat ner den fråga som vi använder gzip i skriptet .. för att komprimera filen .. vi skriver att röret kommer vi att compreess använda gzip
nedan är exempelkoden

#! / usr / bin / ksh

/ usr / sbin / mknod NAMEDPIPE p

gzip -1 <NAMEDPIPE> EXPORT &
DB2 "export till NAMEDPIPE av del SELECT * FROM test" # # DB2 kommandot för att
# # Exportuppgifter
rm-f NAMEDPIPE


Efter färdigställandet av manus, lyckas jag fortfarande se skriptet PID, jag kan inte se samband anknytning till DB, grunden script hänger där gör inget, jag misstänker gzip -1 <NAMEDPIPE> EXPORT & inte termenating ... . korrekt

Tack
Smithk

I skriptet du skapar en bakgrund som läser ur den namngivna röret (gzip).

Nästa du startar en process (db) som skriver att den namngivna pipen.

Så snart skrivprocess (db) gör du tar bort den namngivna röret.

Troligtvis genom att Temne avläsningstillfälle process (gzip) har ännu inte avslutat behandlingen alla data från den namngivna röret.

Eftersom den namngivna röret (och uppgifterna i den) har tagits bort av behandlingen kommer aldrig få en EOF.

I huvudsak gäller behandlingen är kvar med en öppen fil deskriptor som hänvisar till något som inte existerar längre.

Därför gzip kommandot inte säga.

Eftersom detta är ett barn process av ditt manus, skriptet inte kommer att upphöra.

Det bara verkar som om det upphör, allt det gjorde var återkommande kontroll till ditt skal. Under det waitingfor en död som barn.

Efter verkställande ditt manus, jag förväntar mig kommer du inte bara att kunna hitta din script med ps i processen tabellen, men gzip också.

Dessutom, jag förstår varför du använda en namngiven pipe efter något sådant.

Skulle det inte vara mycket enklare att använda:

DB2 "export till EXPORTTILLSTÅND av del väljer * från test"
gzip -1 EXPORT

Jag är inte bekant med db kommando, men jag antar
DB2 "SELECT * FROM test"
skulle producera utdata till skärmen.

Om ja, varför inte använda en "anonym" pipe:
DB2 "SELECT * FROM test" | gzip -1 -> EXPORT.gz

Det kan arbeta med en namngiven pipe och om du slår på 2 kommandon:
:
#! / usr / bin / ksh

/ usr / sbin / mknod NAMEDPIPE p

DB2 "export till NAMEDPIPE av del SELECT * FROM test" & # # DB2 kommandot för att
# # Exportuppgifter
gzip -1 <NAMEDPIPE> EXPORT.gz

rm-f NAMEDPIPE

Jag tror ja
gzip -1 <NAMEDPIPE_FILE> EXPORT_FILE &

orsakar problemet, vi skriftligen till röret eftersom vi inte har tillräckligt med utrymme på filsystemet att exportera data, vi skriver data till Pipe och sedan komprimera i bakgrunden.

vi kan inte göra så här
DB2 "export till NAMEDPIPE av del SELECT * FROM test" &
gzip -1 <NAMEDPIPE> EXPORT.gz

Sedan om vi har något fel på export gillar tabellen inte funnit ... Nästa steg gzip är waitting för PIPEFILE och manus själv hänger utan att gå vidare till nästa steg.


En insikt?

tack
smithk

Du skulle kunna försöka bygga en fördröjning innan du tar bort röret.

sova 30
rm-f NAMEDPIPE