From which environment are you creating the process?
If you're doing it from an environment such as C code, you can fork() and then in the child, send a SIGSTOP to yourself before the exec(), preventing further execution.
A more generic solution (probably best) would be to create a stub that does so. So the stub program would:
- Take arguments consisting of the real program's name and arguments
- send a SIGSTOP to itself
- exec() the real program with appropriate arguments
This will ensure that you avoid any sort of race conditions having to do with the new processing getting too far before you can send a signal to it.
An example for shell:
#!/bin/bash
kill -STOP $$
exec "$@"
And using above code:
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:~$
The jobs -l
shows the PID. But if you're doing it from a shell you don't need the PID directly. You can just do: kill -CONT %1
(assuming you only have one job).
Doing it with more than one job? Left as an exercise for the reader :)