jmd@loral.UUCP (John McDaid) (11/10/88)
Hello, I have a situation where given a process id, I need to find the child(ren) of that pid. The only way I can think of doing this, without execing some kind of shell script that runs ps -l through awk, is to get the necessary information out of the process table via /dev/kmem. I am running DEC 3.0 Ultirx on uVAX 2000. The reason I need to be able to find the child of a given pid is this: I am forking off an xterm process from my program and I need to be able to kill the xterm process at will. The problem is that xterm is set uid to root and it will not except my SIGTERM or SIGKILL. I CANNOT set uid to root the parent process. But, using the pid from xterm as the parent, I can kill the csh that xterm invokes (the child of xterm) and then xterm would itself exit. I am guessing that by using /dev/kmem, I could seek to the offset where the process table starts, and then read through the process table until I find my given pid as a parent pid. The only problem is that I do not know how to calculate the offset. I have looked at the source for ps on 4.3BSD but I seem to think that there has to be an easier way. Can anyone out there help me out with this problem or maybe even suggest a way for me to get rid of the xterm process. Please respond via e-mail. Thanks in advance to anyone that gives this some thought. John McDaid jmd@loral.UUCP
bzs@encore.com (Barry Shein) (11/11/88)
From: jmd@loral.UUCP (John McDaid) >Hello, > >I have a situation where given a process id, I need to find the child(ren) >of that pid. The only way I can think of doing this, without execing >some kind of shell script that runs ps -l through awk, is to get the >necessary information out of the process table via /dev/kmem. Why are you so shy about groveling a ps listing? You don't have to use awk if you're worried about all the overhead/memory, you can use popen() and just get it yourself with a little string manipulation. Think of it this way, given that you'll mostly have to duplicate all of ps's code (it's probably doing it correctly) into yours, and that ps (or your code) will spend most of its time doing I/O on /dev/kmem anyhow the fork/exec of ps is a tiny cost (I could go along with fork/execing things like awk therafter is unacceptable to you, but I doubt you'll get what you want much faster than just forking ps.) If ps seems slow on your system it's probably not the fork overhead, you won't likely do better, there's no such thing as a free brunch. And note that /dev/kmem on many systems is becoming only readable to setgid programs (eg. ps) so if you don't use ps your program may stop working somewhere else, or someday and need a complete rewrite anyhow. And if your code is just a clone of ps you won't be able to give it away. Unless there's some very special reason you don't want to fork ps that you're not telling us I say do it, and get onto unsolved problems. I can't tell you how many times I've just popen'd a ps (or even an ls for that matter, particularly in the days when directory reading was less portable) and I've never been sorry. And I'm very impatient. Do it like the pros, cheat! -Barry Shein, ||Encore||