to find pid of a process

[robinsonvpanicker]

i m executing a program from another program using the "system()" call........and that will run as a background process.....now i want to kill the process...but it seems the kernel does not support ps command nor the killaall command..........nor top command............so how do i kill a process using the name....or by knowing the name how do i find the pid and kill it

[wje_lf]

The easiest way is not to use system() at all. Use fork() and (in the child process) exec(). In the parent process, fork() returns the pid of the child process; in the child process, fork() returns 0, which is how the code knows that it's executing the child process.

Hope this helps.

[robinsonvpanicker]

ya i m trying to exec the program it does not seem to exec.....plz do check what i m doing is correct
pid_t pid;
if((pid=fork())==0){
execve("./CardServer &",NULL);
}
else{
printf("\ngetpid %d",getpid());
}

i also tried using path but it aint execing.......could u help me.........thanks a lot

[wje_lf]

There are several things wrong with this.

1. If you do this at the command line:
   

   man execve

   you'll see that your use of execve() is way, way off. :)
2. For your convenience, don't even use execve(). Use execl() instead. The man page for that does refer you to execve(), but only for details on replacement of the current process. I apologize for not being more explicit when I suggested exec(); there actually is no such standard library function.
3. Remove the space and the ampersand ("&"). Those are shell syntax, and you're not using a shell here (though you would have been if you were using system().
4. You were right to use NULL as the final argument. The first argument is the path to the program. If you're using execl(), any arguments between the first one and the NULL are command line arguments to the program itself. It is customary that the first such command line argument is the name of the program. So between the argument which names the program and the NULL, you need an additional argument: the same argument as the first one, but without the "./".
   
   See the man page for execl() for further details.
5. It's a good idea to make your program as bullet-proof as possible. If everything goes correctly, your child process will not return to your original program after the execl() call, because that process will now be running a different program. But what happens if the new program disappears or something? It's not likely to happen, but unless the design or maintenance cost is prohibitive, it's always a good idea to make your program bulletproof. So in the part of the code which handles the case where the child pid is zero (that is, in the child process code), it's always a good idea to have something just after the execl() call which says, "Oops! Big error here!" and then calls exit() or abort().
6. It's a good idea to make your program as bulletproof as possible. Therefore, instead of just handling the two situations where fork() returns 0 (that would be your child process) and fork() returns the child process's pid (that would be your parent process receiving the pid of the child), it's also a good idea to handle the case where fork() returns -1, which means the fork() failed. This can happen if you exceed the number of child processes allowed for your parent process (usually the result of a bug in your program, and you should always write defensive code which checks for this), or if for some other reason (a similar bug in someone else's program, for example) makes system resources tight. For more information, check the man page for fork().
   
   Making a three-way check for the result of the fork() call will probably make you want to split up that cute combination of calling fork() and checking the result, so that the fork() happens first, and the checking of the resultant pid is a separate if statement, but that's up to you.

[robinsonvpanicker]

thanks that was very very useful information.....i got it working.....thanks alot