Hi Serge,
Thank you for a patch.
I test a patch and will report a result next week.
> Hideo-san, I don't think that we need to introduce a new parameter to
> control verbosity of monitor. There is nothing really important in
> that output.
All right.
I agree that I do not give the log of monitor.
Best Regards,
Hideo Yamauchi.
--- Serge Dubrouski <serge...@gmail.com> wrote:
> Ok, attached are 2 patches for pgsql RA. First adds use for the new
> "-q" option of ocf_run. Second fixes "meta-data" method plus there is
> a rather deep analysis of exit code
>
> Hideo-san, I don't think that we need to introduce a new parameter to
> control verbosity of monitor. There is nothing really important in
> that output.
>
> On Fri, Aug 20, 2010 at 2:45 AM, Dejan Muhamedagic <deja...@fastmail.fm>
> wrote:
> > Hi,
> >
> > On Thu, Aug 19, 2010 at 08:43:38AM -0600, Serge Dubrouski wrote:
> >> Ahh, thanks. I've  got where is the problem, and just wonder if apache
> >> RA suffers from the same issue.
> >>
> >> While it is possible to fix this in RA by not calling get_pgsql_param
> >> if the script was called with for "meta-data" (and in this case that
> >> will be impossible to provide correct default value for scoket_dir if
> >> user changed it in configuration file) I'm not sure if it's correct to
> >> not pass all of OCF_RESKEY parameters down to RA when "meta-data"
> >> function is called. Dejan, what do you think? Shall we create a
> >> Bugzilla for this issue and get it fixed in Pacemaker?
> >
> > The meta-data is most often invoked outside of pacemaker, for
> > instance by 'crm ra' or when the agents are packaged while
> > creating the man pages. It has to function without any
> > parameters. So, get_pgsql_param should not be called if the RA
> > was invoked to produce meta-data.
> >
> > As for defaults for various parameters, that's tricky, and should
> > be avoided if it depends on the content of an external file,
> > because a file can change at any time (also accidentally).
> >
> > Cheers,
> >
> > Dejan
> >
> >> On Thu, Aug 19, 2010 at 1:25 AM,  <renayama19661...@ybb.ne.jp> wrote:
> >> > Hi Serge,
> >> >
> >> > Thank you for comment.
> >> >
> >> > My English interpretation may be wrong, but comments.
> >> >
> >> > $OCF_RESKEY_config is not handed to pgsql even if I set right
> >> > $OCF_RESKEY_config in the
> case of the
> >> > meta-data processing.
> >> >
> >> > static char*
> >> > get_resource_meta(const char* rsc_type, const char* provider)
> >> > {
> >> >        const int BUFF_LEN=4096;
> >> >        int read_len = 0;
> >> >        char buff[BUFF_LEN];
> >> >        char* data = NULL;
> >> >        GString* g_str_tmp = NULL;
> >> >        char ra_pathname[RA_MAX_NAME_LENGTH];
> >> >        FILE* file = NULL;
> >> >        GHashTable * tmp_for_setenv;
> >> >        struct timespec short_sleep = {0,200000000L};
> >> > /*20ms*/
> >> >
> >> >        get_ra_pathname(RA_PATH, rsc_type, provider,
> >> > ra_pathname);
> >> >
> >> >        strncat(ra_pathname, "
meta-data",RA_MAX_NAME_LENGTH-strlen(ra_pathname)-1);
> >> >        tmp_for_setenv = g_hash_table_new(g_str_hash,
> >> > g_str_equal);
> >> >        add_OCF_env_vars(tmp_for_setenv,
> >> > "DUMMY_INSTANCE", rsc_type,
provider); -> ****
> setenv Only
> >> > environment vars. **********
> >> >
> >> >        raexec_setenv(tmp_for_setenv);
> >> >        g_hash_table_foreach_remove(tmp_for_setenv,
> >> > let_remove_eachitem,
NULL);
> >> >        g_hash_table_destroy(tmp_for_setenv);
> >> > (snip)
> >> >
> >> > In addition, when we use logd, this error is given, but it is thrown
> >> > away in ha_log.
> >> >
> >> >> The other option would be to change pgsql RA in a way that it won't
> >> >> parse config file if $OCF_RESKEY_config isn't set and in this case
> >> >> assume that $OCF_RESKEY_socketdir isn't set as well. That could
> >> >> potentially create problems for Ubuntu users for whom that
> >> >> functionality was created.
> >> >
> >> > Yes.
> >> > I know that there is a function of current pgsql for other users.
> >> > But I think that the analysis of config file is not necessary for
> >> > another many users.
> >> > In addition, in our environment, pgsql moves without analysis.
> >> >
> >> > Best Regards,
> >> > Hideo Yamauchi.
> >> >
> >> >
> >> > --- Serge Dubrouski <serge...@gmail.com> wrote:
> >> >
> >> >> Hello Hideo -
> >> >>
> >> >> I'm a bit lost with this info. If I understand you correct your
> >> >> postgresql.conf isn't in /var/lib/pgsql directory and pgsql RA script
> >> >> can't find it if $OCF_RESKEY_config isn't set. Then why not to just
> >> >> simply set $OCF_RESKEY_config and point it to correct place instead of
> >> >> introducing new parameter to disable parsing of configuration file?
> >> >>
> >> >> The other option would be to change pgsql RA in a way that it won't
> >> >> parse config file if $OCF_RESKEY_config isn't set and in this case
> >> >> assume that $OCF_RESKEY_socketdir isn't set as well. That could
> >> >> potentially create problems for Ubuntu users for whom that
> >> >> functionality was created.
> >> >>
> >> >>
> >> >> On Wed, Aug 18, 2010 at 8:46 PM,  <renayama19661...@ybb.ne.jp>
> >> >> wrote:
> >> >> > Hi All,
> >> >> >
> >> >> > We confirmed that an error of pgsql occurred by the setting that we
> >> >> > did not use logd
> for.
> >> >> > When we use a syslog, this occurs.
> >> >> > And when $OCF_RESKEY_config is handled by default, an error occurs
> >> >> > when meta-data
> processing
> >> >> is
> >> >> > performed.
> >> >> > �* OCF_RESKEY_config of the user will not be
> >> >> > /var/lib/pgsql/data in many cases.
> >> >> >
> >> >> > (snip)
> >> >> > Aug 19 11:34:09 srv01 crmd: [9317]: info: match_graph_event: Action
> >> >> prmIpPostgreSQLDB2_monitor_10000
> >> >> > (10) confirmed on srv01 (rc=0)
> >> >> > Aug 19 11:34:09 srv01 pgsql[9870]: INFO: could not change directory to
> >> >> "/var/lib/heartbeat/cores/root"
> >> >> > server starting
> >> >> > Aug 19 11:34:09 srv01 pgsql[9870]: INFO: PostgreSQL start command
> >> >> > sent.
> >> >> > Aug 19 11:34:09 srv01 pgsql[9870]: INFO: PostgreSQL is down
> >> >> > Aug 19 11:34:10 srv01 pgsql[9870]: INFO: PostgreSQL is started.
> >> >> > Aug 19 11:34:10 srv01 pgsql[9975]: ERROR: Cannot find configuration
> >> >> > file
> >> >> > /var/lib/pgsql/data/postgresql.conf ----> ***** An error of the
> >> >> > meta-data processing
> after the
> >> >> start
> >> >> > processing
> >> >> > (snip)
> >> >> > Aug 19 11:35:09 srv01 pgsql[10526]: ERROR: Cannot find configuration
> >> >> > file
> >> >> > /var/lib/pgsql/data/postgresql.conf ----> ***** An error of the
> >> >> > �lrmadmin -M ocf
> pgsql
> >> >> heartbeat
> >> >> > processing
> >> >> > (snip)
> >> >> >
> >> >> > Even if pgsql treats OCF_RESKEY_config by meta-data processing, there
> >> >> > is not a meaning.
> >> >> > Because OCF_RESKEY_config is because it is not set.
> >> >> >
> >> >> > �* ha.cf
> >> >> >
> >> >> > pacemaker on
> >> >> > #use_logd on
> >> >> > debug 0
> >> >> > udpport 694
> >> >> > keepalive 2
> >> >> > warntime 20
> >> >> > deadtime 24
> >> >> > initdead 48
> >> >> > logfacility local1
> >> >> >
> >> >> > The pgsql analyze a config file by get_pgsql_param processing.
> >> >> > There is the problem in this analysis.
> >> >> >
> >> >> > Two revisions think me to be thought.
> >> >> >
> >> >> > Pattern 1) A method to choose analysis of config file in an ocf
> >> >> > parameter.
> >> >> > �* For example, add a parameter of parse_config to pgsql.
> >> >> > �* Because many users do not need analysis of config file.
> >> >> >
> >> >> > Pattern 2) By a call except start,monitor,status,stop, �pgsql
> >> >> > do not do
> get_pgsql_param
> >> >> processing.
> >> >> >
> >> >> > It is the problem that I limited when cluster do not use logd, but
> >> >> > please please tell an
> >> >> opinion of
> >> >> > all of you.
> >> >> >
> >> >> > 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/
>
_______________________________________________________
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/
