kill system call returns error while pid is active

[Klaus Crusius]

I am trying to detect, if a process with a certain pid ist still running by issuing the system call "res = kill(pid, 0)".
Actuall the process was waiting for a ipc-message msgrcv, while all signals were blocked. The process had to be killed with "kill -9 " afterward.
The system call (in another process with same uid and gid) returned -1 and errno was not EPERM.
Is there any explanation why the command did not succeed?
Is there a better way to determine if a porcess of a given pid is running.

[Steven E. Protter]

Shalom,

The PPID or parent process Id might be 1. That would make its parent init. Killing init is the equivalent to killing the whole system, which the OS will not let you do.

SEP

[Klaus Crusius]

Thanks Steven,

the PID of the process I want to kill is not 1, but 10645.
The PPID is of that porcess is 1, because it has been detached from its starting process. The issue only occurs occasionally on hpux11.11. I did not see it on hpux11.00.

Klaus

[James R. Ferguson · Accepted solution]

Hi Klaus:

Performing a 'kill()' with a null signal (0) is indded the appropriate way to ascertain a 'pid's validity.

An value of EPERM for errno will be returned "if The user ID of the sending process is not a user who has appropriate privileges and its real or effective user ID does not match the real or saved user ID of the receiving process." or "The sending and receiving processes are not in the same session and the real or effective user ID does not match the real or saved user ID of the receiving process." according to the manpages.

Regards!

...JRF...

[Klaus Crusius]

Thanks James,

but the errno was not EPERM! So I have the impression the kill call does not behave as I expect, having read the man pages. I was hoping to find somebody with similar experience, maybe a solution.

Klaus

[Don Morris_1]

It would probably help if you mentioned what the error message *was*, not only what it wasn't. That would help narrow things down.

[Klaus Crusius]

Unfortuantely I only know, that errno was not EPERM, because that was checked in the failing program.
I give here the code, which will explain:

if (putback || /* header contains no pid */
( re = kill( pid, 0 ) ) == 0 ||
re < 0 && errno == EPERM )
{
/* this call will block, if no space in queue */
res = msgsnd(qid,msg_buffer,read_size,0);

if ( res >= 0 )
res = 0;
else
text = "lost";
} else {
text = "removed";
res = 1;
}

The program ended up in the else-part, while the process with the given pid was still running.

[Don Morris_1]

Well, the first thing I'd do is add a debugging message detailing re, putback and errno -- but that's me.

Second thing I'd do is validate that pid (which I have to assume is derived from the header structure that putback describes?) is not corrupt. [Perhaps the header has an overrun or other corruption such that the pid is invalid or now negative, etc.] Either debugging statements in the program, using a debugger on the program -- or using something like tusc to capture the actual call to kill() to validate the state.

The man page is correctly listing the only possible error codes for kill(2) based on a quick code inspection (yes, I could have missed something... but in the simplest case where you're passing 0 to a process as you've described, not a group -- there really isn't much variance in the path here...). (By the way -- is qid a different variable (someone got cute with "next pid" perhaps?) or a typo? Not that it matters.. just idle curiosity).

[Klaus Crusius]

Hello everybody,

thanks for your valueable comments. Finally I coudl reproduce the error and found the root cause of the problem. Ther is no issue with the kill system call. I found, that the used pid was invalid under certain sporadic conditions, which explains all my confusion.

Klaus

[Klaus Crusius]

Verified that pid was wrong.