kill 0

[Brandon Metcalf]

I'm seeing a behavior with using "kill 0,$pid" to determine if a
process is running that I didn't expect. It seems that only root can
correctly get the status on processes that root or another user that
is different from the one calling kill() owns. For example,

$ whoami
bmetcalf
$ ps -ef|grep gdm
root 965 1 0 Jul19 ? 00:00:00 /usr/bin/gdm
root 978 965 0 Jul19 ? 00:00:00 /usr/bin/gdm
root 979 978 0 Jul19 ? 00:37:20 /usr/X11R6/bin/X :0 -deferglyphs 16 -nolisten tcp -audit 0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7
bmetcalf 24443 23845 0 09:19 pts/5 00:00:00 grep gdm
$ perl -le '$a = kill 0,965;print $a'
0
$ su
Password:
# perl -le '$a = kill 0,965;print $a'
1

Is this the expected behavior? I'm sure it is since every platform
and version of Perl I've tried behave the same way.

 

[xhoster]

I'm seeing a behavior with using "kill 0,$pid" to determine if a
process is running that I didn't expect. It seems that only root can
correctly get the status on processes that root or another user that
is different from the one calling kill() owns. For example,
....

Is this the expected behavior? I'm sure it is since every platform
and version of Perl I've tried behave the same way.

Given the docs for kill, it is the behavior I would expect (** mine):

If SIGNAL is zero, no signal is sent to the process. This
is a useful way to check that the process is alive and
**hasn't changed its UID.** See perlport for notes on the
portability of this construct.

And by all means, do see perlport.

Xho

 

[Brandon Metcalf]

Given the docs for kill, it is the behavior I would expect (** mine):

If SIGNAL is zero, no signal is sent to the process. This
is a useful way to check that the process is alive and
**hasn't changed its UID.** See perlport for notes on the
portability of this construct.

And by all means, do see perlport.

Sure, I looked at perlport but didn't see anything that explained what
I'm seeing. Also, I don't see anything in the documentation for
kill() what would explain this behavior. You highlighted "hasn't
changed its UID", but I don't understand what that has to do with the
problem.

 

[Brandon Metcalf]

Sure, I looked at perlport but didn't see anything that explained what
I'm seeing. Also, I don't see anything in the documentation for
kill() what would explain this behavior. You highlighted "hasn't
changed its UID", but I don't understand what that has to do with the
problem.

OK. This explains it:

$ ps -ef|grep gdm
root 965 1 0 Jul19 ? 00:00:00 /usr/bin/gdm
root 978 965 0 Jul19 ? 00:00:00 /usr/bin/gdm
root 979 978 0 Jul19 ? 00:40:01 /usr/X11R6/bin/X :0 -deferglyphs 16 -nolisten tcp -audit 0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7
bmetcalf 25710 25677 0 11:45 pts/13 00:00:00 grep gdm
$ perl -le 'kill 0,965 or print $!'
Operation not permitted

So, one has to have permission to actually send a signal 0.

 

[Brandon Metcalf]

I'm seeing a behavior with using "kill 0,$pid" to determine if a
process is running that I didn't expect. It seems that only root can
correctly get the status on processes that root or another user that
is different from the one calling kill() owns. For example,
...

Is this the expected behavior? I'm sure it is since every platform
and version of Perl I've tried behave the same way.

Given the docs for kill, it is the behavior I would expect (** mine):

If SIGNAL is zero, no signal is sent to the process. This
is a useful way to check that the process is alive and
**hasn't changed its UID.** See perlport for notes on the
portability of this construct.

And from the 'man kill' page:

"Only the super-user may send signals to other users' processes."[/QUOTE]


Sure, I read that as well. But Perl's implementation of signal 0 is
special in that it doesn't actually send a signal to the process. It
simply checks to see if it's alive. It doesn't seem that special
permissions would be required to check the existence of a process.

But, per my last post, proper permissions are required.