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/
>> >
>>
>>
>>
>> --
>> 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.
pgsql_patch1
Description: Binary data
pgsql_patch2
Description: Binary data
_______________________________________________________ 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/
