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