Oi
estamos vendo comportamento estranho, quando se executa shell script é executar com êxito, mas é PID é ainda pendurado quando vemos ps-ef | grep script1.ksh até fazemos Kill <PID>


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

Dentro script que estamos usando
saída comando antes da conclusão do script



SO: AIX 5.3.0.0

Alguém pode aconselhar

Deixe-me saber se você precisar de qualquer informação adicional.


obrigado
SmithK

Difícil dizer se você não fornecer o código do script.

Tenho estreitada estabelece o tema que estamos a utilizar no script .. gzip para compactar o arquivo .. que escrevemos para o cano, então vamos compreess usando gzip
abaixo está o código de exemplo

#! / usr / bin / ksh

/ usr / sbin / mknod NAMEDPIPE p

gzip -1 <NAMEDPIPE> Export &
db2 "de exportação para NAMEDPIPE del SELECT * FROM teste" # # db2 comando para
# # Exportar dados
rm-f NAMEDPIPE


Após a conclusão do script, com sucesso, eu ainda vejo o script PID, não vejo ligação nenhuma ligação à DB, basicamente script é pendurada por aí fazendo nada, eu suspeito gzip -1 <NAMEDPIPE> Export & não termenating ... . corretamente

Obrigado
Smithk

No seu script você cria um fundo processo que lê a partir do pipe nomeado (gzip).

Em seguida, você iniciar um processo (PO), que escreve para o pipe nomeado.

Logo que o processo de escrita (DB) é feito de remover o pipe nomeado.

Provavelmente por esse tempo, o processo de leitura (gzip) não concluiu ainda a todos os dados de leitura do pipe nomeado.

Desde o pipe nomeado (e os dados nele) foi removido do processo de leitura nunca irá receber um EOF.

Basicamente o processo de leitura é deixado com um descritor de arquivo aberto que se refere a algo que não existia mais.

Assim, o gzip comando não irá encerrar.

Uma vez que este processo é um processo filho do seu script, o script não irá encerrar.

Ela só parece como se ele terminou, tudo o que fez foi voltar para o seu regresso controle reservatório. Abaixo está esperando é de uma criança morta.

Após executar o script, espero que você não só será capaz de encontrar o seu script com o PS no processo mesa, mas o gzip também.

Além disso, eu entendo porque você usar um pipe nomeado para algo como isto.

Não seria muito mais fácil de usar:

db2 "exportação para a exportação de del SELECT * FROM teste"
gzip -1 EXPORTAÇÃO

Eu não estou familiarizado com o comando db, mas presumo
db2 "SELECT * FROM teste"
iria produzir o resultado para o seu ecrã.

Se assim for, por que não utilizar um "anónimo" pipe:
db2 "SELECT * FROM teste" | gzip -1 -> EXPORT.gz

Pode trabalhar com um pipe nomeado como bem se você alternar os 2 comandos:
:
#! / usr / bin / ksh

/ usr / sbin / mknod NAMEDPIPE p

db2 "de exportação para NAMEDPIPE del SELECT * FROM test" & # # db2 comando para
# # Exportar dados
gzip -1 <NAMEDPIPE> EXPORT.gz

rm-f NAMEDPIPE

Eu acho que sim
gzip -1 <NAMEDPIPE_FILE> EXPORT_FILE &

causando o problema, estamos a escrita para o tubo pois não temos espaço suficiente no sistema para exportar dados, que se escrever dados em Pipe e, em seguida, compactar em segundo plano.

não podemos fazer como este
db2 "de exportação para NAMEDPIPE del SELECT * FROM test" &
gzip -1 <NAMEDPIPE> EXPORT.gz

Uma vez que se tivermos algum erro na exportação como o quadro não foi encontrado ... gzip waitting próximo passo é para o PIPEFILE, eo script em si é pendurado sem proceder à próxima etapa.


Qualquer ideia?

obrigado
smithk

Você poderia tentar construir um atraso antes da remoção do tubo.

sono 30
rm-f NAMEDPIPE