Comment 5 for bug 246735

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

On Wed, Jul 9, 2008 at 6:59 AM, Matt Zimmerman <email address hidden> wrote:
> Why not fix pidofproc itself rather than duplicating the logic?

If a pidfile is available, pidofproc() uses the following to determine if a process is active:
            ...
            if $(kill -0 "${pid:-}" 2> /dev/null); then
                echo "$pid"
                return 0
                return 1 # program is dead and /var/run pid file exists
            fi
            ...

I assume this is to account for zombie processes, where a process exists in the process table, but it will not receive a -0 signal.

The "kill -0" operation is restricted to the owner of the process (and root).

I considered an "else" statement, detecting an "Operation not permitted" error.

But I was concerned that was a serious functional change to the manner in which pidofproc() operates, affecting its many callers. In the interest of getting this patch accepted by Debian (it has been, see Debian Bug #483285), I thought that creating a new function runnable by any user would be the safest approach.

I've attached another patch, that detects an "Operation not permitted" error in the pidofproc() kill call, and returns 100 (in order to preserve a non-zero return code for legacy callers of pidofproc()). This patch does keep a status_of_proc() around, to call pidofproc(), and detect the "0 or 100" return code.

This patch also has a *significant* advantage over its predecssor. Having status_of_proc() call pidofproc() supports pidfiles, something that slangasek and lamont have raised as an issue. I'm subscribing them to this bug for comment.

Note that I chose 100 based on http://refspecs.linux-foundation.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html (100-149 reserved for distribution use).

:-Dustin