-------------- Original message ----------------------
From: "Dan Nicholson" <[EMAIL PROTECTED]>
> On 7/4/07, Dennis J Perkins <[EMAIL PROTECTED]> 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]} ]
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
