Mailing List Archive: Linux-HA: Dev

[Problem]The restraint of the error of pgsql.

Index | Next | Previous | View Threaded

renayama19661014 at ybb

Aug 18, 2010, 7:46 PM

Post #1 of 10 (764 views)
Permalink

[Problem]The restraint of the error of pgsql.

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 [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

sergeyfd at gmail

Aug 18, 2010, 11:04 PM

Post #2 of 10 (738 views)
Permalink

Re: [Problem]The restraint of the error of pgsql. [In reply to]

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, <renayama19661014 [at] ybb> 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 [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
>

--
Serge Dubrouski.
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

renayama19661014 at ybb

Aug 19, 2010, 12:25 AM

Post #3 of 10 (739 views)
Permalink

Re: [Problem]The restraint of the error of pgsql. [In reply to]

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 <sergeyfd [at] gmail> 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, <renayama19661014 [at] ybb> 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 [at] lists
> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> > Home Page: http://linux-ha.org/
> >
>
>
>
> --
> Serge Dubrouski.
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
>

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

sergeyfd at gmail

Aug 19, 2010, 7:43 AM

Post #4 of 10 (736 views)
Permalink

Re: [Problem]The restraint of the error of pgsql. [In reply to]

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, <renayama19661014 [at] ybb> 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 <sergeyfd [at] gmail> 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, <renayama19661014 [at] ybb> 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 [at] lists
>> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> > Home Page: http://linux-ha.org/
>> >
>>
>>
>>
>> --
>> Serge Dubrouski.
>> _______________________________________________________
>> Linux-HA-Dev: Linux-HA-Dev [at] lists
>> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> Home Page: http://linux-ha.org/
>>
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
>

--
Serge Dubrouski.
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

dejanmm at fastmail

Aug 20, 2010, 1:45 AM

Post #5 of 10 (726 views)
Permalink

Re: [Problem]The restraint of the error of pgsql. [In reply to]

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, <renayama19661014 [at] ybb> 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 <sergeyfd [at] gmail> 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, <renayama19661014 [at] ybb> 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 [at] lists
> >> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> >> > Home Page: http://linux-ha.org/
> >> >
> >>
> >>
> >>
> >> --
> >> Serge Dubrouski.
> >> _______________________________________________________
> >> Linux-HA-Dev: Linux-HA-Dev [at] lists
> >> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> >> Home Page: http://linux-ha.org/
> >>
> >
> > _______________________________________________________
> > Linux-HA-Dev: Linux-HA-Dev [at] lists
> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> > Home Page: http://linux-ha.org/
> >
>
>
>
> --
> Serge Dubrouski.
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

sergeyfd at gmail

Aug 20, 2010, 8:42 AM

Post #6 of 10 (724 views)
Permalink

Re: [Problem]The restraint of the error of pgsql. [In reply to]

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 <dejanmm [at] fastmail> 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, <renayama19661014 [at] ybb> 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 <sergeyfd [at] gmail> 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, <renayama19661014 [at] ybb> 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 [at] lists
>> >> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> >> > Home Page: http://linux-ha.org/
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Serge Dubrouski.
>> >> _______________________________________________________
>> >> Linux-HA-Dev: Linux-HA-Dev [at] lists
>> >> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> >> Home Page: http://linux-ha.org/
>> >>
>> >
>> > _______________________________________________________
>> > Linux-HA-Dev: Linux-HA-Dev [at] lists
>> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> > Home Page: http://linux-ha.org/
>> >
>>
>>
>>
>> --
>> Serge Dubrouski.
>> _______________________________________________________
>> Linux-HA-Dev: Linux-HA-Dev [at] lists
>> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> Home Page: http://linux-ha.org/
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
>

--
Serge Dubrouski.

Attachments:

pgsql_patch1 (0.76 KB)

pgsql_patch2 (1.32 KB)

renayama19661014 at ybb

Aug 20, 2010, 4:07 PM

Post #7 of 10 (723 views)
Permalink

Re: [Problem]The restraint of the error of pgsql. [In reply to]

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 <sergeyfd [at] gmail> 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 <dejanmm [at] fastmail> 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,  <renayama19661014 [at] ybb> 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 <sergeyfd [at] gmail> 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,  <renayama19661014 [at] ybb> 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 [at] lists
> >> >> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> >> >> > Home Page: http://linux-ha.org/
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Serge Dubrouski.
> >> >> _______________________________________________________
> >> >> Linux-HA-Dev: Linux-HA-Dev [at] lists
> >> >> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> >> >> Home Page: http://linux-ha.org/
> >> >>
> >> >
> >> > _______________________________________________________
> >> > Linux-HA-Dev: Linux-HA-Dev [at] lists
> >> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> >> > Home Page: http://linux-ha.org/
> >> >
> >>
> >>
>
=== $B0J2<$N%a%C%;!<%8$O>JN,$5$l$^$7$?(B ===> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
>

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

renayama19661014 at ybb

Aug 22, 2010, 7:13 PM

Post #8 of 10 (706 views)
Permalink

Re: [Problem]The restraint of the error of pgsql. [In reply to]

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.

--- renayama19661014 [at] ybb 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 <sergeyfd [at] gmail> 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 <dejanmm [at] fastmail> 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,  <renayama19661014 [at] ybb> 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 <sergeyfd [at] gmail> 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,  <renayama19661014 [at] ybb> 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.
> > >> >> >
>
=== $B0J2<$N%a%C%;!<%8$O>JN,$5$l$^$7$?(B ===

Attachments:

pgsql_patch1_0823 (0.72 KB)

sergeyfd at gmail

Aug 22, 2010, 8:18 PM

Post #9 of 10 (709 views)
Permalink

Re: [Problem]The restraint of the error of pgsql. [In reply to]

Thanks, Hideo! Of course it does need that shift operator there.
Thanks for checking and catching it!

2010/8/22 <renayama19661014 [at] ybb>:
> 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.
>
> --- renayama19661014 [at] ybb 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 <sergeyfd [at] gmail> 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 <dejanmm [at] fastmail> 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,  <renayama19661014 [at] ybb> 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 <sergeyfd [at] gmail> 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,  <renayama19661014 [at] ybb> 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.
>> > >> >> >
>>
> === $B0J2<$N%a%C%;!<%8$O>JN,$5$l$^$7$?(B ===
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
>
>

--
Serge Dubrouski.
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

dejanmm at fastmail

Aug 23, 2010, 9:22 AM

Post #10 of 10 (697 views)
Permalink

Re: [Problem]The restraint of the error of pgsql. [In reply to]

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 <renayama19661014 [at] ybb>:
> > 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.
> >
> > --- renayama19661014 [at] ybb 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 <sergeyfd [at] gmail> 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 <dejanmm [at] fastmail> 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,  <renayama19661014 [at] ybb> 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 <sergeyfd [at] gmail> 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,  <renayama19661014 [at] ybb> 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 [at] lists
> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> > Home Page: http://linux-ha.org/
> >
> >
>
>
>
> --
> Serge Dubrouski.
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads