views:

4813

answers:

6

I've a process name and I've to send a kill() signal to that process but I need its PID to call kill(). I would only like to use:

popen("pidof process_name");

as the last thing. Is there any other way to find out the process' PID? One way I could think of is to send a socket request to that process and ask to its PID.

The other way is a little too complicated for a simple code I'm writing: to do what pidof command's source code is actually doing (it uses a function call find_pid_by_name() but that's doing a lot of things).

If no simple solution is possible, I've to do this:

system("pkill <process_name>");

and check its return code. But will pkill be available for sure on all Linux machines?

+3  A: 

Use sysctl - Example code

EDIT - it is available in Linux see here

Martin Beckett
Thanks a lot! I'll look into this.
artknish
This only works on *BSD, not Linux.
ephemient
A: 

This seems to work fine for me.

You might want to give the full path of the process though, lest you kill a process that has a similar name.

The main advantage of this is that you can specify the signal that you want to send.

system("killall -s 9 process_name");
partoa
This is no different than the pkill version...
Greg Rogers
+3  A: 

You mentioned you were using linux. It isn't the cleanest solution, but you can go through every entry in /proc and check the process name in cmdline against what you are looking for.

Greg Rogers
should be pretty straight forward using boost::regex and boost::filesystem i think
Johannes Schaub - litb
i once looked into the strace output of pidof, and figured it does it the same way. (may have changed in between, though)
Johannes Schaub - litb
procfs reads are VERY cheap. For this particular purpose, you would not have to start really reading until you reach PID 1000, then you have 40 - 60 to examine. Don't think of it like reading a conventional FS, its much cheaper.
Tim Post
A: 

why not to use fcntl with F_GETOWN ?

eSKon
That works only if calling fcntl on a socket descriptor and care must be taken to realize if your getting a PID or a process group (a negative result from fcntl). Calling fcntl on a normal file with F_GETOWN is unspecified in POSIX. http://www.opengroup.org/onlinepubs/009695399/functions/fcntl.html
Tim Post
+1  A: 

Procfs reads are very cheap, many people think of iterating through /proc like they would iterating through / , its really not the case at all.

Save some time by skipping any entry that is under 1000, there's no sense in examining kernel threads. So, basically .. after opendir(), if strtoint() thinks the entry is an int , and that int is greater than or equal to 1000, just read /proc/%d/stat.

Try to avoid the urge to just resolve the 'exe' link, as that is not going to tell you the state of the process that will be receiving the signal. For instance, if the target is in state 'D' (disk sleep), you'd want to know as the signal will not be immediately delivered, or perhaps never, if the D state is perennial.

On most systems, there's going to be 70 - 120 processes to examine and you'll often find your target way before reaching the end.

Tim Post
@tinkertim: Thanks for the tip, didn't know reading in /proc is not like reading a FS!
artknish
+1  A: 

You mention, "One way I could think of is to send a socket request to that process and ask to its PID." It sounds like the process you are trying to kill is a program you wrote.

If that's the case, the cannonical thing to do is to store the pid in a file (usually under /var/run, if you have access to it) while the program is running, and remove the file when the program exits. That way, detecting whether or not the program is running is as simple as

if kill -0 $(cat /var/run/myprog.pid 2>/dev/null) 2>/dev/null; then
    echo Running!
else
    rm -f /var/run/myprog.pid
    echo "Not running."
end

Careful study of all the implications of the above code will probably teach you a lot about how PID files work. Or you can just ask for a more detailed explanation.

Curt Sampson