Malte Forkel wrote:
> In a bash script, I ran into a problem using ps. It seems to me, that it
> takes some time before a newly created process is detected by ps.
No. The ps command will see all currently running processes. If ps
is not listing the process then it is because the process is not (yet)
running.
> Here is what I do: In a bash script, I start a programm using su,
> something like
> nice su myuser -c mycommand &
> SUPID=$!
The 'nice' command is /usr/bin/nice which will exec(2) the next
command in the argument list which in this case is 'su'. You have
asked su to run the command through the /bin/sh with the -c option
which will either exec or not depending upon whether you include shell
metacharacters in your command. Simple commands will be exec'd to
save a process. But complex shell commands will invoke a shell to
handle the command.
SUPID is the process id of the outermost process. In this case it
will be the process id of the 'su' command. You already know this
because you are using the --ppid option to select based upon the
parent. But if it is a complex command then there will be another
shell process between 'mycommand' and the 'su'.
> Because I might have to later send a signal to the mycommand process
> later, I then try to determine ist PID:
> CMDPID=$(ps -f --ppid $SUPID -C mycommand | awk 'NR == 2 { print $2 }')
> To my surprise, CMDPID often was empty. I wrapped the above line into a
> loop and found that it might take 2 or 3 attempts until ps finds the
> process and CMDPID is set.
I didn't look very closely at your problem but I believe you have a
race condition. You are starting up nice, which exec's su, which then
depending upon the argument string either exec's the command directy
or exec's a shell to process the command. Only after all of that will
your command be started. That isn't instantaneous. Especially on a
loaded system you could easily get a ps listing before the sequence
has launched your command.
> Now, here are my questions:
> - Is this a pure timing issue, i.e. should 'sleep 1' before the call to
> ps reliably solve the problem?
While that will /probably/ work most of the time it isn't guaranteed.
It might take longer than a second. This is launched as an
asynchronous process and asynchronous means that the various processes
proceed at their own rates.
> - Is there a better way to determine the PID of the mycommand process?
If you can't have the process you want write out its own process id
directly then I think I would loop waiting for the process to show up.
Start with no delay at all because you might get lucky and that is
fastest. Then add a small delay and try again. Do this a few times
waiting for the process to show up. If it doesn't show up after a
loop timeout, say 30 seconds, then you can detect this and report the
problem.
Bob
Attachment:
signature.asc
Description: Digital signature