pidofproc function in functions script

dennisjperkins at comcast.net dennisjperkins at comcast.net
Wed Jul 18 06:45:31 PDT 2007


 -------------- Original message ----------------------
From: "Dan Nicholson" <dbn.lists at gmail.com>
> On 7/4/07, Dennis J Perkins <dennisjperkins at comcast.net> wrote:
> > I played with pidofproc and this seems to work properly.  I don't know
> > if it would integrate into your functions without any changes.
> 
> I've had a look, and I like what you've done. It may need to be
> massaged a bit to maintain compatibility in the LFS bootscripts,
> though. I also added lfs-dev in case some more eyes want to shine on
> here.

Ok.  Part of this is experimentation to see if I understand it correctly.

> > I used getopts instead of your while loop.  I discovered that t does not
> > detect options after a parameter.
> 
> That's probably true. I'm a little uncomfortable using getopts since
> we don't use it anywhere else, but it is in the POSIX spec, so it's
> safe to use.

If there is only a single option, it's probably simpler to use "if" instead.

> > I also included an exit code for a syntax error, but LSB doesn't call
> > for it.  Since pidofproc is meant to be called by other functions, it
> > might not be that useful anyway.
> 
> I like errors on syntax abuse.
> 
> > It also returns a list of found pids.  LSB specifies exit codes but is
> > silent on return vaues.
> 
> I think that's the way to go.
> 
> > pidofproc()
> > {
> >     local base    # basename of program
> >     local opt     # option currently being processed
> >     local pid     # pid from pidfile
> >     local pids    # list of pids to return to calling function
> >     local pidfile # pidfile passed to pidofproc
> >     local pidlist # list of pids to be returned to calling function
> 
> This is actually an important change. Currently the other functions
> rely on the side effect that pidlist is global. We can change those
> other functions (this way is much cleaner, IMO), but there may be
> scripts out in the wild that depend on the current functionality. I
> didn't find any in either of the current LFS or BLFS bootscripts,
> though.
> 
> >     while getopts ":p:" opt
> >     do
> >         case $opt in
> >             p ) pidfile=$OPTARG ;;
> >             * ) log_error_msg $usage
> >                 exit 2 ;;  # Syntax error
> >         esac
> >     done
> >     shift $((OPTIND - 1 ))
> 
> You removed the -s option, which was kind of nice when you just wanted
> to know if it was running and didn't care what the output was. I
> suppose it's not LSB supported, but we may need it to be LFS supported
> :) I haven't checked out the situation with the current scripts.

I just followed LSB specifications.  The exit code or pidlist would indicate that, but I didn't check to see if any LFS scripts use -s.

> >     # If a pidfile was not passed, look for one in /var/run.
> >     base=${process##*/}
> >     ${pidfile:=/var/run/$base.pid} 2> /dev/null
> 
> I would sort of like to kill this section since I think it's kind of
> evil to "guess" a pidfile when it wasn't specifically asked for. This
> would change existing behavior for current bootscripts. statusproc
> currently does something like this, too.

LSB specifies this behavior.  It also specifies that LSB-compliant daemons should create a pidfile in /var/run.  I don't know how many don't do this, however.

> >     if [ -f "$pidfile" ]; then
> I think this is not quite right. If I asked you to look at
> /var/run/dbus.pid (as opposed to it just being guessed above), then
> that is exactly what I want to be looking at. If it doesn't exist,
> then it's not running from my perspective. The whole reason I passed
> in the pidfile is so we don't just go blindly searching for any
> process named dbus.

I'll look at this again.

> >         # LSB specifies that only the first line of the pidfile should
> > be read.
> >         read pidlist < $pidfile
> 
> I see. We're not exactly LSB compliant, but that should be good enough.

I don't know if a pidfile ever has multiple lines, so the result might be the same either way.
 
> >     else
> >         # No pidfile.  Try to find pid anyway.
> >         pidlist=$(pidof -s $$ -o $PPID -x $process)
> >         if [ -z "$pidlist" ]; then
> >             return 3  # Not running
> >         fi
> >     fi
> > -
> >     # Build list of pids of running processes.
> >     for pid in "$pidlist"
> 
> pidlist can't be quoted here or it will result in a single argument
> for all pids.

Typo.  I hit that after I sent the script.


I have considered looking for pids in /proc.  It does away with the dependency on pidof.

if [ -d /proc/$pid ]; then ...

Fedora also checks that the /proc/$pid is a number:   if [ -z ${pid//[0-9]} ]



More information about the lfs-support mailing list