pcp
[Top] [All Lists]

Re: [PATCH] installing pcp requires `which`

To: "Michael Newton" <kimbrr@xxxxxxx>
Subject: Re: [PATCH] installing pcp requires `which`
From: nscott@xxxxxxxxxx
Date: Wed, 12 Mar 2008 16:48:50 +1100 (EST)
Cc: pcp@xxxxxxxxxxx
Importance: Normal
In-reply-to: <Pine.SGI.4.58.0803121351200.93987974@xxxxxxxxxxxxxxxxxxxxxxx>
References: <Pine.SGI.4.58.0803121351200.93987974@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: pcp-bounce@xxxxxxxxxxx
User-agent: SquirrelMail/1.4.8-4.el4.centos
> We have had a longstanding puzzle as to why, when a whole-machine image
> that includes pcp is constructed in a chroot, pcp is chkconfig off when
> the image comes to be used. Turns out to be due to `which` not being
> available in the rpm post-install ops in the chroot.

Nasty business.

> Investigation suggests that using `which` from bash can be unsafe even
> when its available,

Can you elaborate on that a bit more?  (does this not affect "type"?)

> so the best solution seems to be to use `type` instead
> in these cases. Here I simply say, use `type` if `sh -c 'type -p sh'`
> succeeds (I think this makes sense for linux/bash); otherwise use which

Can we not always use "type"?  No, looks like not - ksh doesn't support it.

> There are other uses of `which` elsewhere that can be switched over to
> also use $PCP_SH_WHICH should it ever turn out that there are any real

PCP_WHICH_PROG would be more consistent with everything else
(like PCP_ECHO_PROG, which can also be a shell built-in).

> systems that dont install `which`, or if there are problems caused
> by `which` using a different PATH to that used by bash.

In practice though the latter shouldn't be an issue, since all the PCP
startup
scripts use /etc/pcp.env, which explicitly sets $PATH to something known
good.

===========================================================================
> pcp/build/rpm/pcp.spec.in
> ===========================================================================

> @@ -135,9 +136,11 @@
>       $PCP_RC_DIR/pmie stop >/dev/null 2>&1
>       [ -x $PCP_RC_DIR/pmproxy ] && PCP_RC_DIR/pmproxy stop >/dev/null 2>&1
>       rm -f $PCP_VAR_DIR/pmns/.NeedRebuild
> +    else
> +     PCP_SH_WHICH=type
>      fi

That seems brave... :|  But its the best of a bad lot, AFAICS.

>      #
>      # the chkconfig thing
>      #

Completely useless comment, maybe nuke while you're there?  Or at some point,
anyway.

> ===========================================================================
> pcp/build/rpm/pro.spec.in
> ===========================================================================
>

Kinda hard to review that one for you, sorry.  :)

> --- a/pcp/build/rpm/pro.spec.in       2008-03-10 22:34:37.000000000 -0700
> +++ b/pcp/build/rpm/pro.spec.in       2008-03-10 21:42:35.882225055 -0700
> @@ -182,8 +182,11 @@
>      if [ -f /etc/pcp.env ] ; then
>          . /etc/pcp.env
>       $PCP_RC_DIR/pmclusterd stop >/dev/null 2>&1

pmclusterd, eh?  What's that when its at home?  Do I even want to know?  :)

> +which=which
> +if sh -c 'type -p sh' >/dev/null 2>&1
> +then
> +    which=type
> +fi
> +AC_SUBST(which)

Looks OK.  I think we should allow it to be forced to something through an
environment variable though (again, like ECHO), to be sure, to be sure.

> +# which
> +PCP_SH_WHICH=@which@

I'd prefer PCP_WHICH_PROG for consistency.

cheers.

--
Nathan


<Prev in Thread] Current Thread [Next in Thread>