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 <serge...@gmail.com> wrote:
> On Mon, Sep 20, 2010 at 1:53 AM, <renayama19661...@ybb.ne.jp> 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 <serge...@gmail.com> wrote:
> >
> >> On Sat, Sep 18, 2010 at 8:26 PM, �<renayama19661...@ybb.ne.jp>
> >> 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 <serge...@gmail.com> 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, <renayama19661...@ybb.ne.jp>
> >> >> 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/
>
=== 以下のメッセージは省略されました ===
_______________________________________________________
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/
