Hi, On Sun, Aug 22, 2010 at 09:18:12PM -0600, Serge Dubrouski wrote: > Thanks, Hideo! Of course it does need that shift operator there. > Thanks for checking and catching it!
Both patches pushed. Thanks! Dejan > 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/ _______________________________________________________ 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/