De qual ambiente você está criando o processo?
Se você estiver fazendo isso de um ambiente como o código C, você pode fork () e, em seguida, no filho, enviar um SIGSTOP para si mesmo antes do exec (), evitando a execução posterior.
Uma solução mais genérica (provavelmente melhor) seria criar um stub que o faça. Então o programa stub iria:
- Aceite argumentos que consistam no nome e nos argumentos do programa real
- envia um SIGSTOP para si mesmo
- exec () o programa real com argumentos apropriados
Isso garantirá que você evite qualquer tipo de condição de corrida relacionada ao novo processamento que esteja muito longe antes de poder enviar um sinal para ele.
Um exemplo para o shell:
#!/bin/bash
kill -STOP $$
exec "$@"
E usando o codez acima:
michael@challenger:~$ ./stopcall.sh ls -al stopcall.sh
[1]+ Stopped ./stopcall.sh ls -al stopcall.sh
michael@challenger:~$ jobs -l
[1]+ 23143 Stopped (signal) ./stopcall.sh ls -al stopcall.sh
michael@challenger:~$ kill -CONT 23143; sleep 1
-rwxr-xr-x 1 michael users 36 2011-07-24 22:48 stopcall.sh
[1]+ Done ./stopcall.sh ls -al stopcall.sh
michael@challenger:~$
O jobs -l
mostra o PID. Mas se você estiver fazendo isso a partir de um shell, não precisará do PID diretamente. Você pode fazer apenas: kill -CONT %1
(supondo que você tenha apenas um emprego).
Fazendo isso com mais de um emprego? Deixado como um exercício para o leitor:)