Re: [Linux-ha-dev] Patch for ocf_run in .ocf_shullfuncs
Hi, On Thu, Sep 16, 2010 at 08:41:50AM -0600, Serge Dubrouski wrote: > Dejan - > > Did you not notice this patch or it's no good? > > There was also a small patch for pgsql a couple weeks ago. The patch is applied, including a set of appropriate changes for some resource agents to reflect the new behaviour of ocf_run. We'll have to include an explanation in the changelog for the next release to warn people running their own resource agents. Thanks, Dejan > Thanks. > > > On Tue, Sep 14, 2010 at 10:13 AM, Serge Dubrouski wrote: > > Hello - > > > > Attached is a patch for ocf_run function in .ocf_shellfunc. The patch > > make ocf_run to return an actual exit code from the command it ran. > > That allows RAs to implement a better logic for handling error > > situations. Following RAs use ocf_run function: > > > > apache > > exportfs > > ICP > > iSCSILogicalUnit > > iSCSITarget > > LVM > > mysql > > ServerRAID > > Squid > > syslog-ng > > > > Most of them do not check error code from ocf_run or check that is > > zero/non zero. pgsql has some extended logic to provide additional > > information to the client based on that error code. So the patch will > > benefit pgsql and won't hurt other RAs. > > > > Thanks. > > > > -- > > Serge Dubrouski. > > > > > > -- > Serge Dubrouski. > ___ > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Patch for ocf_run in .ocf_shullfuncs
Hi Serge,
> You are absolutely right. The sleep command wouldn't completely
> prevent that message. But you have to trade here. In case if
> PostgreSQL really has problems and isn't able to start having that
> additional logging will help to troubleshoot the issue.
I agree, too
If sleep of two seconds helps the solution of the problem, in adding sleep, I
do not have the
objection.
> > I think that we change by environment and the situation of the load of the
> > CPU in time that
> start of
> > postgres takes.
>
> Does it mean that introducing a new OCF parameter, something like
> OCF_RESKEY_timeout_before_first_monitor, sounds like a wise idea?
No.
Even if I added an option, I think that the problem cannot be settled well.
Step1) Start postgreSQL.
runasowner "$OCF_RESKEY_pgctl $pgctl_options start"
Step2) The first monitor is carried out.
pgsql_monitor warn
ocf_run records error log when the practice of the monitor gives back 2 here.
Here, ocf_run should record log by warning.
There is not the conclusive evidence that the first monitor becomes 0 even if I
add an option.
> >> >> > ocf_run() {
> >> >> > (snip)
> >> >> >else
> >> >> >if [ ! -z "$output" ]; then
> >> >> >ocf_log err "$output"
> >> >> >else
> >> >> >ocf_log err "command failed: $*"
> >> >> >fi
> >> >> >return $rc
> >> >> >fi
> >> >> > }
I think that we have to introduce the change of the log output level into
ocf_run.
I think about a change of this ocf_run now.
Best Regards,
Hideo Yamauchi.
--- Serge Dubrouski wrote:
> On Mon, Sep 20, 2010 at 1:53 AM, wrote:
> > Hi Serge,
> >
> >> I know about that issue. The easy fix would be to all a sleep command
> >> just after
> >>
> >> runasowner "$OCF_RESKEY_pgctl $pgctl_options start"
> >>
> >> So it'll look like:
> >>
> >> � � # Invoke pg_ctl
> >> � � runasowner "$OCF_RESKEY_pgctl $pgctl_options start"
> >>
> >> � � if [ $? -eq 0 ]; then
> >> � � � � # Probably started.
> >> � � � � ocf_log info "PostgreSQL start command
> >> sent."
> >> � � else
> >> � � � � ocf_log err "Can't start PostgreSQL."
> >> � � � � return $OCF_ERR_GENERIC
> >> � � fi
> >>
> >> � � sleep 2
> >>
> >> � � while :
> >> � � do
> >
> > I do not think that sleep of two seconds can wait for start of postgres
> > surely.
>
> You are absolutely right. The sleep command wouldn't completely
> prevent that message. But you have to trade here. In case if
> PostgreSQL really has problems and isn't able to start having that
> additional logging will help to troubleshoot the issue.
>
> >
> > I think that we change by environment and the situation of the load of the
> > CPU in time that
> start of
> > postgres takes.
>
> Does it mean that introducing a new OCF parameter, something like
> OCF_RESKEY_timeout_before_first_monitor, sounds like a wise idea?
>
> >
> > Best Regards,
> > Hideo Yamauchi.
> >
> >
> >
> > --- Serge Dubrouski wrote:
> >
> >> On Sat, Sep 18, 2010 at 8:26 PM, �
> >> wrote:
> >> > Hi Serge,
> >> >
> >> > Thank you for comment.
> >> >
> >> >> Do you think that changing that "ocf_log $loglevel" to "ocf_log err"
> >> >> will be better?
> >> >
> >> >
> >> > Is your opinion the next change?
> >> >
> >> > (snip)
> >> > elif [ $rc -eq 2 ]; then
> >> > ocf_log err "Connection error
> >> > (connection to the
> server
> > went bad and the --->
> >> > $loglevel->err this???
> >>
> >> Yes.
> >>
> >> >
> >> > (snip)
> >> >
> >> > By the start handling of pgsql, the monitor processing does not succeed
> >> > immediately.
> >> > It is recorded in log by an error to success when we perform this change.
> >> >
> >> > After all this confuses an operator.
> >>
> >> I know about that issue. The easy fix would be to all a sleep command
> >> just after
> >>
> >> runasowner "$OCF_RESKEY_pgctl $pgctl_options start"
> >>
> >> So it'll look like:
> >>
> >> � � # Invoke pg_ctl
> >> � � runasowner "$OCF_RESKEY_pgctl $pgctl_options start"
> >>
> >> � � if [ $? -eq 0 ]; then
> >> � � � � # Probably started.
> >> � � � � ocf_log info "PostgreSQL start command
> >> sent."
> >> � � else
> >> � � � � ocf_log err "Can't start PostgreSQL."
> >> � � � � return $OCF_ERR_GENERIC
> >> � � fi
> >>
> >> � � sleep 2
> >>
> >> � � while :
> >> � � do
> >>
> >> >
> >> > However, it is considerably troublesome to let ocf_run support loglevel.
> >> >
> >> > I think a little more, too.
> >> >
> >> > Best Regards,
> >> > Hideo Yamauchi.
> >> >
> >> >
> >> > --- Serge Dubrouski wrote:
> >> >
> >> >> Do you think that changing that "ocf_log $loglevel" to "ocf_log err"
> >> >> will be better?
> >> >>
> >> >> Thanks.
> >> >>
> >> >> On Fri, Sep 17, 2010 at 12:48 AM,
> >> >> wrote:
> >> >> > Hi Serge,
> >> >> >
> >> >> > When we use ocf_run in some pgsql, a problem is left.
> >> >> >
> >> >> > In ocf_run, ocf_run outputs log as an error in the case of 2 the
> >> >> > practice result of the
> >> >> command.
Re: [Linux-ha-dev] Patch for ocf_run in .ocf_shullfuncs
On Mon, Sep 20, 2010 at 1:53 AM, wrote:
> Hi Serge,
>
>> I know about that issue. The easy fix would be to all a sleep command
>> just after
>>
>> runasowner "$OCF_RESKEY_pgctl $pgctl_options start"
>>
>> So it'll look like:
>>
>> # Invoke pg_ctl
>> runasowner "$OCF_RESKEY_pgctl $pgctl_options start"
>>
>> if [ $? -eq 0 ]; then
>> # Probably started.
>> ocf_log info "PostgreSQL start command sent."
>> else
>> ocf_log err "Can't start PostgreSQL."
>> return $OCF_ERR_GENERIC
>> fi
>>
>> sleep 2
>>
>> while :
>> do
>
> I do not think that sleep of two seconds can wait for start of postgres
> surely.
You are absolutely right. The sleep command wouldn't completely
prevent that message. But you have to trade here. In case if
PostgreSQL really has problems and isn't able to start having that
additional logging will help to troubleshoot the issue.
>
> I think that we change by environment and the situation of the load of the
> CPU in time that start of
> postgres takes.
Does it mean that introducing a new OCF parameter, something like
OCF_RESKEY_timeout_before_first_monitor, sounds like a wise idea?
>
> Best Regards,
> Hideo Yamauchi.
>
>
>
> --- Serge Dubrouski wrote:
>
>> On Sat, Sep 18, 2010 at 8:26 PM, wrote:
>> > Hi Serge,
>> >
>> > Thank you for comment.
>> >
>> >> Do you think that changing that "ocf_log $loglevel" to "ocf_log err"
>> >> will be better?
>> >
>> >
>> > Is your opinion the next change?
>> >
>> > (snip)
>> > elif [ $rc -eq 2 ]; then
>> > ocf_log err "Connection error
>> > (connection to the server
> went bad and the --->
>> > $loglevel->err this???
>>
>> Yes.
>>
>> >
>> > (snip)
>> >
>> > By the start handling of pgsql, the monitor processing does not succeed
>> > immediately.
>> > It is recorded in log by an error to success when we perform this change.
>> >
>> > After all this confuses an operator.
>>
>> I know about that issue. The easy fix would be to all a sleep command
>> just after
>>
>> runasowner "$OCF_RESKEY_pgctl $pgctl_options start"
>>
>> So it'll look like:
>>
>> # Invoke pg_ctl
>> runasowner "$OCF_RESKEY_pgctl $pgctl_options start"
>>
>> if [ $? -eq 0 ]; then
>> # Probably started.
>> ocf_log info "PostgreSQL start command sent."
>> else
>> ocf_log err "Can't start PostgreSQL."
>> return $OCF_ERR_GENERIC
>> fi
>>
>> sleep 2
>>
>> while :
>> do
>>
>> >
>> > However, it is considerably troublesome to let ocf_run support loglevel.
>> >
>> > I think a little more, too.
>> >
>> > Best Regards,
>> > Hideo Yamauchi.
>> >
>> >
>> > --- Serge Dubrouski wrote:
>> >
>> >> Do you think that changing that "ocf_log $loglevel" to "ocf_log err"
>> >> will be better?
>> >>
>> >> Thanks.
>> >>
>> >> On Fri, Sep 17, 2010 at 12:48 AM,
>> >> wrote:
>> >> > Hi Serge,
>> >> >
>> >> > When we use ocf_run in some pgsql, a problem is left.
>> >> >
>> >> > In ocf_run, ocf_run outputs log as an error in the case of 2 the
>> >> > practice result of the
>> >> command.
>> >> >
>> >> > ocf_run() {
>> >> > (snip)
>> >> > else
>> >> > if [ ! -z "$output" ]; then
>> >> > ocf_log err
>> >> > "$output"
>> >> > else
>> >> > ocf_log err
>> >> > "command failed: $*"
>> >> > fi
>> >> > return $rc
>> >> > fi
>> >> > }
>> >> >
>> >> > But, in pgsql side, the log is output by an error or warning in the
>> >> > case of 2 the practice
>> >> result of
>> >> > the command by a loglevel variable.
>> >> >
>> >> >
>> >> > pgsql_monitor() {
>> >> > local loglevel
>> >> > (snip)
>> >> > runasowner -q "$OCF_RESKEY_psql $psql_options -c 'select
>> >> > now();'"
>> >> >
>> >> > rc=$?
>> >> > if [ $rc -ne 0 ]; then
>> >> > ocf_log $loglevel "PostgreSQL
>> >> > $OCF_RESKEY_pgdb isn't running"
>> >> > if [ $rc -eq 1 ]; then
>> >> > ocf_log err "Fatal error (out
>> >> > of memory, file not
>> found,
>> > etc.) occurred while
>> >> executing
>> >> > the psql command."
>> >> > elif [ $rc -eq 2 ]; then
>> >> > ocf_log $loglevel "Connection
>> >> > error (connection to
>> the
>> > server went bad and the
>> >> session was
>> >> > not interactive) occurred while executing the psql command."
>> >> > elif [ $rc -eq 3 ]; then
>> >> > ocf_log err "Script error (the
>> >> > variable
>> ON_ERROR_STOP was
>> > set) occurred while
>> >> executing
>> >> > the psql command."
>> >> > fi
>> >> > return $OCF_ERR_GENERIC
>> >> > fi
>> >> > (snip)
>> >> >
>> >> > This difference confuses an operator.
>> >> >
>> >> > Best Regards,
>> >> > Hideo Yamauchi.
>> >> >
>> >> >
>> >> > ___
>> >> > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
>> >> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> >> > Home Page: http://linux-ha.org/
>> >> >
>> >>
>> >
Re: [Linux-ha-dev] Patch for ocf_run in .ocf_shullfuncs
Hi Serge,
> I know about that issue. The easy fix would be to all a sleep command
> just after
>
> runasowner "$OCF_RESKEY_pgctl $pgctl_options start"
>
> So it'll look like:
>
> # Invoke pg_ctl
> runasowner "$OCF_RESKEY_pgctl $pgctl_options start"
>
> if [ $? -eq 0 ]; then
> # Probably started.
> ocf_log info "PostgreSQL start command sent."
> else
> ocf_log err "Can't start PostgreSQL."
> return $OCF_ERR_GENERIC
> fi
>
> sleep 2
>
> while :
> do
I do not think that sleep of two seconds can wait for start of postgres surely.
I think that we change by environment and the situation of the load of the CPU
in time that start of
postgres takes.
Best Regards,
Hideo Yamauchi.
--- Serge Dubrouski wrote:
> On Sat, Sep 18, 2010 at 8:26 PM, wrote:
> > Hi Serge,
> >
> > Thank you for comment.
> >
> >> Do you think that changing that "ocf_log $loglevel" to "ocf_log err"
> >> will be better?
> >
> >
> > Is your opinion the next change?
> >
> > (snip)
> > elif [ $rc -eq 2 ]; then
> > ocf_log err "Connection error
> > (connection to the server
went bad and the --->
> > $loglevel->err this???
>
> Yes.
>
> >
> > (snip)
> >
> > By the start handling of pgsql, the monitor processing does not succeed
> > immediately.
> > It is recorded in log by an error to success when we perform this change.
> >
> > After all this confuses an operator.
>
> I know about that issue. The easy fix would be to all a sleep command
> just after
>
> runasowner "$OCF_RESKEY_pgctl $pgctl_options start"
>
> So it'll look like:
>
> # Invoke pg_ctl
> runasowner "$OCF_RESKEY_pgctl $pgctl_options start"
>
> if [ $? -eq 0 ]; then
> # Probably started.
> ocf_log info "PostgreSQL start command sent."
> else
> ocf_log err "Can't start PostgreSQL."
> return $OCF_ERR_GENERIC
> fi
>
> sleep 2
>
> while :
> do
>
> >
> > However, it is considerably troublesome to let ocf_run support loglevel.
> >
> > I think a little more, too.
> >
> > Best Regards,
> > Hideo Yamauchi.
> >
> >
> > --- Serge Dubrouski wrote:
> >
> >> Do you think that changing that "ocf_log $loglevel" to "ocf_log err"
> >> will be better?
> >>
> >> Thanks.
> >>
> >> On Fri, Sep 17, 2010 at 12:48 AM, wrote:
> >> > Hi Serge,
> >> >
> >> > When we use ocf_run in some pgsql, a problem is left.
> >> >
> >> > In ocf_run, ocf_run outputs log as an error in the case of 2 the
> >> > practice result of the
> >> command.
> >> >
> >> > ocf_run() {
> >> > (snip)
> >> > else
> >> > if [ ! -z "$output" ]; then
> >> > ocf_log err
> >> > "$output"
> >> > else
> >> > ocf_log err
> >> > "command failed: $*"
> >> > fi
> >> > return $rc
> >> > fi
> >> > }
> >> >
> >> > But, in pgsql side, the log is output by an error or warning in the case
> >> > of 2 the practice
> >> result of
> >> > the command by a loglevel variable.
> >> >
> >> >
> >> > pgsql_monitor() {
> >> > local loglevel
> >> > (snip)
> >> > runasowner -q "$OCF_RESKEY_psql $psql_options -c 'select
> >> > now();'"
> >> >
> >> > rc=$?
> >> > if [ $rc -ne 0 ]; then
> >> > ocf_log $loglevel "PostgreSQL
> >> > $OCF_RESKEY_pgdb isn't running"
> >> > if [ $rc -eq 1 ]; then
> >> > ocf_log err "Fatal error (out
> >> > of memory, file not
> found,
> > etc.) occurred while
> >> executing
> >> > the psql command."
> >> > elif [ $rc -eq 2 ]; then
> >> > ocf_log $loglevel "Connection
> >> > error (connection to
> the
> > server went bad and the
> >> session was
> >> > not interactive) occurred while executing the psql command."
> >> > elif [ $rc -eq 3 ]; then
> >> > ocf_log err "Script error (the
> >> > variable
> ON_ERROR_STOP was
> > set) occurred while
> >> executing
> >> > the psql command."
> >> > fi
> >> > return $OCF_ERR_GENERIC
> >> > fi
> >> > (snip)
> >> >
> >> > This difference confuses an operator.
> >> >
> >> > Best Regards,
> >> > Hideo Yamauchi.
> >> >
> >> >
> >> > ___
> >> > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> >> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> >> > Home Page: http://linux-ha.org/
> >> >
> >>
> >>
> >>
> >> --
> >> Serge Dubrouski.
> >> ___
> >> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> >> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> >> Home Page: http://linux-ha.org/
> >>
> >
> > ___
> > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> > Home Page: http://linux-ha.org/
> >
>
>
>
> --
> Serge Dubrouski.
> ___
> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> http
Re: [Linux-ha-dev] Patch for ocf_run in .ocf_shullfuncs
On Sat, Sep 18, 2010 at 8:26 PM, wrote:
> Hi Serge,
>
> Thank you for comment.
>
>> Do you think that changing that "ocf_log $loglevel" to "ocf_log err"
>> will be better?
>
>
> Is your opinion the next change?
>
> (snip)
> elif [ $rc -eq 2 ]; then
> ocf_log err "Connection error (connection to the server went bad
> and the --->
> $loglevel->err this???
Yes.
>
> (snip)
>
> By the start handling of pgsql, the monitor processing does not succeed
> immediately.
> It is recorded in log by an error to success when we perform this change.
>
> After all this confuses an operator.
I know about that issue. The easy fix would be to all a sleep command
just after
runasowner "$OCF_RESKEY_pgctl $pgctl_options start"
So it'll look like:
# Invoke pg_ctl
runasowner "$OCF_RESKEY_pgctl $pgctl_options start"
if [ $? -eq 0 ]; then
# Probably started.
ocf_log info "PostgreSQL start command sent."
else
ocf_log err "Can't start PostgreSQL."
return $OCF_ERR_GENERIC
fi
sleep 2
while :
do
>
> However, it is considerably troublesome to let ocf_run support loglevel.
>
> I think a little more, too.
>
> Best Regards,
> Hideo Yamauchi.
>
>
> --- Serge Dubrouski wrote:
>
>> Do you think that changing that "ocf_log $loglevel" to "ocf_log err"
>> will be better?
>>
>> Thanks.
>>
>> On Fri, Sep 17, 2010 at 12:48 AM, wrote:
>> > Hi Serge,
>> >
>> > When we use ocf_run in some pgsql, a problem is left.
>> >
>> > In ocf_run, ocf_run outputs log as an error in the case of 2 the practice
>> > result of the
>> command.
>> >
>> > ocf_run() {
>> > (snip)
>> > else
>> > if [ ! -z "$output" ]; then
>> > ocf_log err
>> > "$output"
>> > else
>> > ocf_log err
>> > "command failed: $*"
>> > fi
>> > return $rc
>> > fi
>> > }
>> >
>> > But, in pgsql side, the log is output by an error or warning in the case
>> > of 2 the practice
>> result of
>> > the command by a loglevel variable.
>> >
>> >
>> > pgsql_monitor() {
>> > local loglevel
>> > (snip)
>> > runasowner -q "$OCF_RESKEY_psql $psql_options -c 'select
>> > now();'"
>> >
>> > rc=$?
>> > if [ $rc -ne 0 ]; then
>> > ocf_log $loglevel "PostgreSQL $OCF_RESKEY_pgdb
>> > isn't running"
>> > if [ $rc -eq 1 ]; then
>> > ocf_log err "Fatal error (out of
>> > memory, file not found,
> etc.) occurred while
>> executing
>> > the psql command."
>> > elif [ $rc -eq 2 ]; then
>> > ocf_log $loglevel "Connection
>> > error (connection to the
> server went bad and the
>> session was
>> > not interactive) occurred while executing the psql command."
>> > elif [ $rc -eq 3 ]; then
>> > ocf_log err "Script error (the
>> > variable ON_ERROR_STOP was
> set) occurred while
>> executing
>> > the psql command."
>> > fi
>> > return $OCF_ERR_GENERIC
>> > fi
>> > (snip)
>> >
>> > This difference confuses an operator.
>> >
>> > Best Regards,
>> > Hideo Yamauchi.
>> >
>> >
>> > ___
>> > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
>> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> > Home Page: http://linux-ha.org/
>> >
>>
>>
>>
>> --
>> Serge Dubrouski.
>> ___
>> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
>> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> Home Page: http://linux-ha.org/
>>
>
> ___
> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
>
--
Serge Dubrouski.
___
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Patch for ocf_run in .ocf_shullfuncs
Hi Serge,
Thank you for comment.
> Do you think that changing that "ocf_log $loglevel" to "ocf_log err"
> will be better?
Is your opinion the next change?
(snip)
elif [ $rc -eq 2 ]; then
ocf_log err "Connection error (connection to the server went bad
and the --->
$loglevel->err this???
(snip)
By the start handling of pgsql, the monitor processing does not succeed
immediately.
It is recorded in log by an error to success when we perform this change.
After all this confuses an operator.
However, it is considerably troublesome to let ocf_run support loglevel.
I think a little more, too.
Best Regards,
Hideo Yamauchi.
--- Serge Dubrouski wrote:
> Do you think that changing that "ocf_log $loglevel" to "ocf_log err"
> will be better?
>
> Thanks.
>
> On Fri, Sep 17, 2010 at 12:48 AM, wrote:
> > Hi Serge,
> >
> > When we use ocf_run in some pgsql, a problem is left.
> >
> > In ocf_run, ocf_run outputs log as an error in the case of 2 the practice
> > result of the
> command.
> >
> > ocf_run() {
> > (snip)
> > else
> > if [ ! -z "$output" ]; then
> > ocf_log err "$output"
> > else
> > ocf_log err "command
> > failed: $*"
> > fi
> > return $rc
> > fi
> > }
> >
> > But, in pgsql side, the log is output by an error or warning in the case of
> > 2 the practice
> result of
> > the command by a loglevel variable.
> >
> >
> > pgsql_monitor() {
> > local loglevel
> > (snip)
> > runasowner -q "$OCF_RESKEY_psql $psql_options -c 'select
> > now();'"
> >
> > rc=$?
> > if [ $rc -ne 0 ]; then
> > ocf_log $loglevel "PostgreSQL $OCF_RESKEY_pgdb
> > isn't running"
> > if [ $rc -eq 1 ]; then
> > ocf_log err "Fatal error (out of
> > memory, file not found,
etc.) occurred while
> executing
> > the psql command."
> > elif [ $rc -eq 2 ]; then
> > ocf_log $loglevel "Connection
> > error (connection to the
server went bad and the
> session was
> > not interactive) occurred while executing the psql command."
> > elif [ $rc -eq 3 ]; then
> > ocf_log err "Script error (the
> > variable ON_ERROR_STOP was
set) occurred while
> executing
> > the psql command."
> > fi
> > return $OCF_ERR_GENERIC
> > fi
> > (snip)
> >
> > This difference confuses an operator.
> >
> > Best Regards,
> > Hideo Yamauchi.
> >
> >
> > ___
> > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> > Home Page: http://linux-ha.org/
> >
>
>
>
> --
> Serge Dubrouski.
> ___
> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
>
___
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Patch for ocf_run in .ocf_shullfuncs
Do you think that changing that "ocf_log $loglevel" to "ocf_log err"
will be better?
Thanks.
On Fri, Sep 17, 2010 at 12:48 AM, wrote:
> Hi Serge,
>
> When we use ocf_run in some pgsql, a problem is left.
>
> In ocf_run, ocf_run outputs log as an error in the case of 2 the practice
> result of the command.
>
> ocf_run() {
> (snip)
> else
> if [ ! -z "$output" ]; then
> ocf_log err "$output"
> else
> ocf_log err "command failed: $*"
> fi
> return $rc
> fi
> }
>
> But, in pgsql side, the log is output by an error or warning in the case of 2
> the practice result of
> the command by a loglevel variable.
>
>
> pgsql_monitor() {
> local loglevel
> (snip)
> runasowner -q "$OCF_RESKEY_psql $psql_options -c 'select now();'"
>
> rc=$?
> if [ $rc -ne 0 ]; then
> ocf_log $loglevel "PostgreSQL $OCF_RESKEY_pgdb isn't running"
> if [ $rc -eq 1 ]; then
> ocf_log err "Fatal error (out of memory, file not found, etc.)
> occurred while executing
> the psql command."
> elif [ $rc -eq 2 ]; then
> ocf_log $loglevel "Connection error (connection to the server went
> bad and the session was
> not interactive) occurred while executing the psql command."
> elif [ $rc -eq 3 ]; then
> ocf_log err "Script error (the variable ON_ERROR_STOP was set)
> occurred while executing
> the psql command."
> fi
> return $OCF_ERR_GENERIC
> fi
> (snip)
>
> This difference confuses an operator.
>
> Best Regards,
> Hideo Yamauchi.
>
>
> ___
> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
>
--
Serge Dubrouski.
___
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Patch for ocf_run in .ocf_shullfuncs
Hi Serge, On Thu, Sep 16, 2010 at 08:41:50AM -0600, Serge Dubrouski wrote: > Dejan - > > Did you not notice this patch or it's no good? Still behind with the ML traffic after the vacation. > There was also a small patch for pgsql a couple weeks ago. OK. The patch is fine, it's just that some RA do need to change too. After identifying and fixing single RAs we can apply the patch. Cheers, Dejan > Thanks. > > > On Tue, Sep 14, 2010 at 10:13 AM, Serge Dubrouski wrote: > > Hello - > > > > Attached is a patch for ocf_run function in .ocf_shellfunc. The patch > > make ocf_run to return an actual exit code from the command it ran. > > That allows RAs to implement a better logic for handling error > > situations. Following RAs use ocf_run function: > > > > apache > > exportfs > > ICP > > iSCSILogicalUnit > > iSCSITarget > > LVM > > mysql > > ServerRAID > > Squid > > syslog-ng > > > > Most of them do not check error code from ocf_run or check that is > > zero/non zero. pgsql has some extended logic to provide additional > > information to the client based on that error code. So the patch will > > benefit pgsql and won't hurt other RAs. > > > > Thanks. > > > > -- > > Serge Dubrouski. > > > > > > -- > Serge Dubrouski. > ___ > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Patch for ocf_run in .ocf_shullfuncs
Hi Serge,
When we use ocf_run in some pgsql, a problem is left.
In ocf_run, ocf_run outputs log as an error in the case of 2 the practice
result of the command.
ocf_run() {
(snip)
else
if [ ! -z "$output" ]; then
ocf_log err "$output"
else
ocf_log err "command failed: $*"
fi
return $rc
fi
}
But, in pgsql side, the log is output by an error or warning in the case of 2
the practice result of
the command by a loglevel variable.
pgsql_monitor() {
local loglevel
(snip)
runasowner -q "$OCF_RESKEY_psql $psql_options -c 'select now();'"
rc=$?
if [ $rc -ne 0 ]; then
ocf_log $loglevel "PostgreSQL $OCF_RESKEY_pgdb isn't running"
if [ $rc -eq 1 ]; then
ocf_log err "Fatal error (out of memory, file not found, etc.)
occurred while executing
the psql command."
elif [ $rc -eq 2 ]; then
ocf_log $loglevel "Connection error (connection to the server went
bad and the session was
not interactive) occurred while executing the psql command."
elif [ $rc -eq 3 ]; then
ocf_log err "Script error (the variable ON_ERROR_STOP was set)
occurred while executing
the psql command."
fi
return $OCF_ERR_GENERIC
fi
(snip)
This difference confuses an operator.
Best Regards,
Hideo Yamauchi.
___
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Patch for ocf_run in .ocf_shullfuncs
Dejan - Did you not notice this patch or it's no good? There was also a small patch for pgsql a couple weeks ago. Thanks. On Tue, Sep 14, 2010 at 10:13 AM, Serge Dubrouski wrote: > Hello - > > Attached is a patch for ocf_run function in .ocf_shellfunc. The patch > make ocf_run to return an actual exit code from the command it ran. > That allows RAs to implement a better logic for handling error > situations. Following RAs use ocf_run function: > > apache > exportfs > ICP > iSCSILogicalUnit > iSCSITarget > LVM > mysql > ServerRAID > Squid > syslog-ng > > Most of them do not check error code from ocf_run or check that is > zero/non zero. pgsql has some extended logic to provide additional > information to the client based on that error code. So the patch will > benefit pgsql and won't hurt other RAs. > > Thanks. > > -- > Serge Dubrouski. > -- Serge Dubrouski. ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
