Hi All,

Thank you for a lot of comment.

> >> > � � � if [ -f $PIDFILE ]
> >> > � � � then
> >> > � � � � � PID=`head -n 1 $PIDFILE`
> >> > - � � � � kill -s 0 $PID >/dev/null 2>&1 && 
> >> > fuser
$OCF_RESKEY_pgdata
> >> > 2>&1 | grep $PID >/dev/null 2>&1
> >> > + � � � � runasowner "kill -s 0 $PID 
> >> > >/dev/null 2>&1"
> >> > � � � � � return $?
> >> > � � � fi

The change to very beginning fuser was performed with the next patch.

 * http://www.gossamer-threads.com/lists/linuxha/dev/67871

Because runasowner uses ocf_run in latest pgsql, I think that RA can support 
some instance of
postgres. 

And the patch of Dejan is better than the patch which I suggested.

I think that a patch of Dejan works definitely.

Best Regards,
Hideo Yamauchi.

--- Serge Dubrouski <[email protected]> wrote:

> On Thu, Nov 4, 2010 at 2:22 PM, Lars Ellenberg
> <[email protected]> wrote:
> > On Thu, Nov 04, 2010 at 04:52:49PM +0100, Dejan Muhamedagic wrote:
> >> Hi,
> >>
> >> On Thu, Nov 04, 2010 at 08:54:02AM -0600, Serge Dubrouski wrote:
> >> > Honestly I've never liked that fuser. No doubt that it's too expensive
> >> > to run it in every status/monitor operation. But this proposed
> >> > solution make pgsql RA incompatible with other operation systems,
> >> > Solaris in particular. So instead I'd propose following patch:
> >> >
> >> > @@ -441,7 +441,7 @@
> >> > &#65533; &#65533; &#65533; if [ -f $PIDFILE ]
> >> > &#65533; &#65533; &#65533; then
> >> > &#65533; &#65533; &#65533; &#65533; &#65533; PID=`head -n 1 $PIDFILE`
> >> > - &#65533; &#65533; &#65533; &#65533; kill -s 0 $PID >/dev/null 2>&1 && 
> >> > fuser
$OCF_RESKEY_pgdata
> >> > 2>&1 | grep $PID >/dev/null 2>&1
> >> > + &#65533; &#65533; &#65533; &#65533; runasowner "kill -s 0 $PID 
> >> > >/dev/null 2>&1"
> >> > &#65533; &#65533; &#65533; &#65533; &#65533; return $?
> >> > &#65533; &#65533; &#65533; fi
> >> >
> >> > It would guarantee that process with that PID is up and owned by
> >> > pg_dba user. I believe that here we can assume that that process is
> >> > PosgressSQL database. Further check with running sql monitor will make
> >> > it sure.
> >> >
> >> > The complete patch is attached.
> >>
> >> This looks good enough to me. If nobody other objects, I'd apply
> >> this patch.
> >
> > Dejan, you asked it yourself:
> > why do we need to kill $PID at all, anyways?
> > Why not directly do the sql monitoring?
> 
> It's possible to configure pgsql RA to monitor database over Virtual
> IP, not over local UNIX socket. In this case if there were no first
> status check for process PID (actually that pgsql_status function)
> monitor function would succeed on all cluster nodes that were able to
> connect to Virtual IP. That would break a whole cluster. So doing
> status check before SQL monitoring guarantees that PostgreSQL is
> running locally on a node where ra runs.
> 
> >
> > --
> > : Lars Ellenberg
> > : LINBIT | Your Way to High Availability
> > : DRBD/HA support and consulting http://www.linbit.com
> >
> > DRBD&#65533; and LINBIT&#65533; are registered trademarks of LINBIT, 
> > Austria.
> > _______________________________________________________
> > Linux-HA-Dev: [email protected]
> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> > Home Page: http://linux-ha.org/
> >
> 
> 
> 
> -- 
> Serge Dubrouski.
> _______________________________________________________
> Linux-HA-Dev: [email protected]
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
> 

_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Reply via email to