I'm starting a long-running process (in Java, on the off-chance that's relevant) and would like to then capture its PID via ps.  I'm essentially doing this:Process longRunningProcess = new ProcessBuilder(...).start();Process psProcess = new ProcessBuilder(ps).start();psProcess.waitFor();// extract the PID from the output of psProcessOr effectively equivalently in Bash:$ long_running_process > /dev/null & psThe question is, is it possible for the long-running process to be in some still-starting-up state that ps will not yet report?  Or is there any sort of guarantee that by the time ps is executed the long-running process will be started-up enough to be visible?  Running the command repeatedly appears to always include the process, but that's obviously not proof of anything.This article warns that there may be a race-condition on commands started after ps is started (e.g. ps | grep) but doesn't mention anything about processes started before ps.
Is there any risk of a race condition when runing ps?
ps;background process
If the operations are comparable to OpenJDK v6-b14, the PID will be available to ps when scanning the /proc virtual file system. You cannot be sure that the process has really started (i.e. done anything); all you know is that a PID has been reserved and scheduled (come to think of it, the process might have died and be in a zombie state).However, since ps locks you to Unix systems, you could use Reflection to dig into the object returned by ProcessBuilder on the understanding that it will lead you to a UnixProcess:final class  [More ...] UNIXProcess extends Process {    private FileDescriptor stdin_fd;    private FileDescriptor stdout_fd;    private FileDescriptor stderr_fd;    private int pid; <----------------------------------------------    private int exitcode;Of course this is a hack, but not too different from spawning ps - and surely faster. And not really all that risky - I don't see a pid field called pid changing very soon.