Pegar a session ID de processo assim que o mesmo for disparado [RESOLVIDO]

lucasgrohl
(usa Ubuntu)

Enviado em 07/05/2012 - 17:55h

Pessoal,

Estou precisando disparar um processo no Unix e logo em seguida eu preciso associar seu session ID à uma variável para fazer uma verificação no final do meu script.

Alguém poderia me ajudar em como fazer isso?

Seria algo como...

procid=fastload < script.fload

obs1: "procid" é aonde eu quero o session ID do meu processo fastload.
obs2: Eu não posso buscar apenas pelo nome do processo pois podem haver mais de um fastload send executado.
obs3: Fastload é um utilitário do banco Teradata, com o qual eu trabalho.

O script vai disparar um monte de coisa, mas no final eu preciso ter certeza de que o Fastload terminou para que o script geral possa ser finalizado.

Desde já obrigado à todos! (Y)

Abraço!

AprendiNoLinux
(usa Ubuntu)

Enviado em 07/05/2012 - 18:32h

O comando wait lida com processos em background.
Imagine que seu script dispare este utilitário mesmo em background por várias vários clones/processos deste.
Você pode deixar o wait no aguardo da resposta. Quando ele terminar você receberá a resposta. exemplo:

#!/bin/bash

# Meu Script chamador 

while true; do

   #chamando em background

   bash seuoutroscript param1 param2 param3 &

   wait # aguardando a conclusão do outro script.

done



exit

 

Este seu script chamador pode entrar via bg também. Quando o processo do outro script terminar, seu script chamador vai saber.

Hoje em dia não faço mais desta forma. Costumo disparar vários outros scripts, as vezes até 500, mas uso arquivos de lock para saber quem está trabalhando.
Se preciso forçar alguém finalizar uma tarefa, lanço arquivos físicos de STOP gravados fisicamente no hd q se existirem, forçam o script que está em bg finalizar.
Controlo centenas de scripts em bg desta forma e tem sido a mais segura.

Se o seu script chamado não pode gerar arquivos de lock ou ficar em loop para verificar se existe algum arquivo de trava a opção é usar wait.

Outra opção que uso com frequência é o trap para remover scripts que estão trabalhando em bg.

No início dos scripts que preciso interromper a qualquer hora coloco esta instrução.

trap FN_encerra_gserv $USER_INTERRUPT TERM INT HUP SIGINT SIGTERM

A função abaixo cumpre a tarefa que precisa fazer recebendo o script em execução via trap de quem disparou. No caso um único arquivo de LOCK pode tirar os outros do ar.

#-----------------------------------------------------------------------------#

#  name: FN_control_c()

#  @param

#  @return - Sai do sistema. 

#

function FN_control_c()

{

local lc_aplication 

lc_aplication="${PROGNAME}"

	echo

	echo "#################################################"

	echo "## Encerrando o DAEMON $lc_aplication !!!! "

	echo "#################################################"

	echo

	echo " DENTRO DO CONTROL_C PARA SAIR "

	echo " arquivo LOCK: ${ARQ_LOCK} "

	# Função: StopTarefa dentro de libs.

    StopTarefa	"$FILE_PARA_GERAL_SERVICE" \

				"$ARQ_STOP" \

				"$ARQ_LOCK" 2>/dev/null

    if [ -f "${ARQ_LOCK}" ]; then

    	rm "${ARQ_LOCK}" 2>/dev/null

    fi

    if [ -f "${ARQ_STOP}" ]; then

    	rm "${ARQ_STOP}" 2>/dev/null

    fi

	exit 0

}





function zz_fim()

{

: #FIM: EOF()

}

 

AprendiNoLinux
(usa Ubuntu)

Enviado em 07/05/2012 - 20:27h

Veja também esses tópicos:

http://www.vivaolinux.com.br/topico/Shell-Script/Shell-Script-com-autocontrolando-caso-esteja-em-bac...

http://www.vivaolinux.com.br/topico/Shell-Script/Shell-script-funciona-no-comando-mas-nao-no-crontab.

Talvez não resolva seu problema, mas vai te dar uma luz sobre como resolver o seu caso. ;)

rai3mb
(usa Outra)

Enviado em 07/05/2012 - 21:48h

processo & PID=$!

Exemplo prático

totem & PID=$!

a variável PID vai receber o valor do ID do ultimo processo executado


vamos matar o totem


KILL -9 $PID


totem morto!

lucasgrohl
(usa Ubuntu)

Enviado em 08/05/2012 - 11:06h

Valeu pessoal! Consegui fazer e agora está funcionando que é uma beleza! (Y)

Aproveitando, o tópico aberto... eu gostaria de tirar uma dúvida rápida, se possível...

Por acaso o Linux tem algum limite na quantidade parâmetros enviados para um cat, por exemplo?

Pergunto isso pois eu tenho um processo que precisa enviar 40.000 arquivos para um pipe. Para isso, ele car uma concatenação de caminhos de arquivos num cat, direcionando-os para o pipe (ex.: $ cat /dir/file1.txt /dir/file2.txt /dir/file3.txt ... /dir/file40000.txt > pipe.out ).

Ele enviar 0 registros para o pipe, mas quando faço o teste enviando somente 100 arquivos, ele roda de boa.

Alguém daria algum palpite?

Obrigado pela resposta anterior, e desde já obrigado pela ajuda na nova questão! (Y)

rai3mb
(usa Outra)

Enviado em 08/05/2012 - 11:15h

A principio vc deveria marcar esse tópico como resolvido, escolher a melhor resposta, caso julgue existir, e abrir um novo.

Mas vamos lá...


Fiz um teste assim:

for i in $(seq 40000); do echo $(( $i + 10 )) >> arquivo_"$i"; done

depois:

cat arquivo* > /tmp/log


Funcionou, bom no seu caso como vc está passando os parâmetros para o cat? Acredito que não seja um a um até os 40 mil, então o problema pode ser o tamanho dos arquivos, já que fiz com cada um deles com uma linha ;-)

lucasgrohl
(usa Ubuntu)

Enviado em 08/05/2012 - 11:27h

Valeu cara, eu vou tentar ver aqui o pode ser. Os arquivos não são "muito" grandes, no final são aproximadamente 170 milhões de registros, mas isoladamente, são até tranquilos.

Vou marcar o tópico como resolvido e mais uma vez, valeu pela ajuda! (Y)

rai3mb
(usa Outra)

Enviado em 08/05/2012 - 11:30h

Outra coisa, analise bem o seu problema, pois vc vai mesmo querer ter um único arquivo com 170 milhões de registros (linhas)??