On 20 December 2010 01:04, Peter Miller <pmil...@opensource.org.au> wrote: > Quick quiz: is there a way, from outside a process, to know enough about > a process to separate out the following cases... > > ptrace(2) can return ESRCH when > > (a) The specified process does not exist, or > (b) is not currently being traced by the caller, or > (c) is not stopped (for requests that require that). > > As for which requests require the subject process to be stopped, I can > read kernel source for that. > > (a) is easy, use kill(pid, 0) and look at errno. > > However, I can't think of a way to separate (b) and (c). > Ideas?
"Being traced by the caller" still (maybe?) means the caller is temporarily the parent of the process under investigation. So if that's not true, that would falsify b. However, in other cases, you might be the parent anyhow. (c) you should be able to detect by waitpid(child, .., WNOHANG) and testing WIFSTOPPED(..) though that has the drawback it will actually collect it if it has stopped. Alternatively you could look in /proc/$pid/status which should say whether it's stopped or not. > > > Why this sudden interest in ptrace? Tridge suggested that "explain > --trace command..." could run the command tell you what went wrong. That would be great. But how you you determine which of the many syscalls was the one that mattered? This would be a little like the "WHY" command in AmigaDOS :-) http://winuaehelp.back2roots.org/background/amigados.htm -- Martin _______________________________________________ coders mailing list coders@slug.org.au http://lists.slug.org.au/listinfo/coders
