Thanks, Hideo! Of course it does need that shift operator there.
Thanks for checking and catching it!
2010/8/22 <renayama19661...@ybb.ne.jp>:
> Hi Serge,
>
> Thanks!!
>
> I confirmed your patch in postgresql-8.4.4 on RHEL5.5.
> Of course it combined Cluster-Resource-Agents-784385d01d0f.tar and confirmed
> it.
>
> There were some problems to your patch.
> I revised it as follows.
>
> runasowner() {
> local quietrun=""
> [ "x$1" = "x-q" ] && {
> quietrun="-q"
> shift 1 -------> need shift!!
> }
>
> ocf_run $quietrun su $OCF_RESKEY_pgdba -c "$*"
> }
>
> The problem was solved with your patch.
> Let a development version please reflect a patch.
>
> I attach the first patch which I changed.
>
> Best Regards,
> Hideo Yamauchi.
>
> --- renayama19661...@ybb.ne.jp wrote:
>
>> 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.
>> > >> >> >
>>
> === 以下のメッセージは省略されました ===
>
> _______________________________________________________
> 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/
