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/
> >
>
>
>
> --
> 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/
