On 20 Feb 2014, at 4:18 am, Andrey Groshev <gre...@yandex.ru> wrote:
> > > 19.02.2014, 06:47, "Andrew Beekhof" <and...@beekhof.net>: >> On 18 Feb 2014, at 9:29 pm, Andrey Groshev <gre...@yandex.ru> wrote: >> >>> Hi, ALL and Andrew! >>> >>> Today is a good day - I killed a lot, and a lot of shooting at me. >>> In general - I am happy (almost like an elephant) :) >>> Except resources on the node are important to me eight processes: >>> corosync,pacemakerd,cib,stonithd,lrmd,attrd,pengine,crmd. >>> I killed them with different signals (4,6,11 and even 9). >>> Behavior does not depend of number signal - it's good. >>> If STONITH send reboot to the node - it rebooted and rejoined the cluster >>> - too it's good. >>> But the behavior is different from killing various demons. >>> >>> Turned four groups: >>> 1. corosync,cib - STONITH work 100%. >>> Kill via any signals - call STONITH and reboot. >> >> excellent >> >>> 3. stonithd,attrd,pengine - not need STONITH >>> This daemons simple restart, resources - stay running. >> >> right >> >>> 2. lrmd,crmd - strange behavior STONITH. >>> Sometimes called STONITH - and the corresponding reaction. >>> Sometimes restart daemon >> >> The daemon will always try to restart, the only variable is how long it >> takes the peer to notice and initiate fencing. >> If the failure happens just before a they're due to receive totem token, the >> failure will be very quickly detected and the node fenced. >> If the failure happens just after, then detection will take longer - giving >> the node longer to recover and not be fenced. >> >> So fence/not fence is normal and to be expected. >> >>> and restart resources with large delay MS:pgsql. >>> One time after restart crmd - pgsql don't restart. >> >> I would not expect pgsql to ever restart - if the RA does its job properly >> anyway. >> In the case the node is not fenced, the crmd will respawn and the the PE >> will request that it re-detect the state of all resources. >> >> If the agent reports "all good", then there is nothing more to do. >> If the agent is not reporting "all good", you should really be asking why. >> >>> 4. pacemakerd - nothing happens. >> >> On non-systemd based machines, correct. >> >> On a systemd based machine pacemakerd is respawned and reattaches to the >> existing daemons. >> Any subsequent daemon failure will be detected and the daemon respawned. > > And! I almost forgot about IT! > Exist another (NORMAL) the variants, the methods, the ideas? > Without this ... @$%#$%&$%^&$%^&##@#$$^$%& !!!!! > Otherwise - it's a full epic fail ;) -ENOPARSE > >>> And then I can kill any process of the third group. They do not restart. >> >> Until they become needed. >> Eg. if the DC goes to invoke the policy engine, that will fail causing the >> crmd to fail and the node to be fenced. >> >>> Generaly don't touch corosync,cib and maybe lrmd,crmd. >>> >>> What do you think about this? >>> The main question of this topic - we decided. >>> But this varied behavior - another big problem. >>> >>> 17.02.2014, 08:52, "Andrey Groshev" <gre...@yandex.ru>: >>>> 17.02.2014, 02:27, "Andrew Beekhof" <and...@beekhof.net>: >>>>> With no quick follow-up, dare one hope that means the patch worked? :-) >>>> Hi, >>>> No, unfortunately the chief changed my plans on Friday and all day I was >>>> engaged in a parallel project. >>>> I hope that today have time to carry out the necessary tests. >>>>> On 14 Feb 2014, at 3:37 pm, Andrey Groshev <gre...@yandex.ru> wrote: >>>>>> Yes, of course. Now beginning build world and test ) >>>>>> >>>>>> 14.02.2014, 04:41, "Andrew Beekhof" <and...@beekhof.net>: >>>>>>> The previous patch wasn't quite right. >>>>>>> Could you try this new one? >>>>>>> >>>>>>> http://paste.fedoraproject.org/77123/13923376/ >>>>>>> >>>>>>> [11:23 AM] beekhof@f19 ~/Development/sources/pacemaker/devel ☺ # git >>>>>>> diff >>>>>>> diff --git a/crmd/callbacks.c b/crmd/callbacks.c >>>>>>> index ac4b905..d49525b 100644 >>>>>>> --- a/crmd/callbacks.c >>>>>>> +++ b/crmd/callbacks.c >>>>>>> @@ -199,8 +199,7 @@ peer_update_callback(enum crm_status_type type, >>>>>>> crm_node_t * node, const void *d >>>>>>> stop_te_timer(down->timer); >>>>>>> >>>>>>> flags |= node_update_join | node_update_expected; >>>>>>> - crm_update_peer_join(__FUNCTION__, node, >>>>>>> crm_join_none); >>>>>>> - crm_update_peer_expected(__FUNCTION__, node, >>>>>>> CRMD_JOINSTATE_DOWN); >>>>>>> + crmd_peer_down(node, FALSE); >>>>>>> check_join_state(fsa_state, __FUNCTION__); >>>>>>> >>>>>>> update_graph(transition_graph, down); >>>>>>> diff --git a/crmd/crmd_utils.h b/crmd/crmd_utils.h >>>>>>> index bc472c2..1a2577a 100644 >>>>>>> --- a/crmd/crmd_utils.h >>>>>>> +++ b/crmd/crmd_utils.h >>>>>>> @@ -100,6 +100,7 @@ void crmd_join_phase_log(int level); >>>>>>> const char *get_timer_desc(fsa_timer_t * timer); >>>>>>> gboolean too_many_st_failures(void); >>>>>>> void st_fail_count_reset(const char * target); >>>>>>> +void crmd_peer_down(crm_node_t *peer, bool full); >>>>>>> >>>>>>> # define fsa_register_cib_callback(id, flag, data, fn) do { >>>>>>> \ >>>>>>> fsa_cib_conn->cmds->register_callback( >>>>>>> \ >>>>>>> diff --git a/crmd/te_actions.c b/crmd/te_actions.c >>>>>>> index f31d4ec..3bfce59 100644 >>>>>>> --- a/crmd/te_actions.c >>>>>>> +++ b/crmd/te_actions.c >>>>>>> @@ -80,11 +80,8 @@ send_stonith_update(crm_action_t * action, const >>>>>>> char *target, const char *uuid) >>>>>>> crm_info("Recording uuid '%s' for node '%s'", uuid, target); >>>>>>> peer->uuid = strdup(uuid); >>>>>>> } >>>>>>> - crm_update_peer_proc(__FUNCTION__, peer, crm_proc_none, NULL); >>>>>>> - crm_update_peer_state(__FUNCTION__, peer, CRM_NODE_LOST, 0); >>>>>>> - crm_update_peer_expected(__FUNCTION__, peer, >>>>>>> CRMD_JOINSTATE_DOWN); >>>>>>> - crm_update_peer_join(__FUNCTION__, peer, crm_join_none); >>>>>>> >>>>>>> + crmd_peer_down(peer, TRUE); >>>>>>> node_state = >>>>>>> do_update_node_cib(peer, >>>>>>> node_update_cluster | node_update_peer | >>>>>>> node_update_join | >>>>>>> diff --git a/crmd/te_utils.c b/crmd/te_utils.c >>>>>>> index ad7e573..0c92e95 100644 >>>>>>> --- a/crmd/te_utils.c >>>>>>> +++ b/crmd/te_utils.c >>>>>>> @@ -247,10 +247,7 @@ tengine_stonith_notify(stonith_t * st, >>>>>>> stonith_event_t * st_event) >>>>>>> >>>>>>> } >>>>>>> >>>>>>> - crm_update_peer_proc(__FUNCTION__, peer, crm_proc_none, >>>>>>> NULL); >>>>>>> - crm_update_peer_state(__FUNCTION__, peer, CRM_NODE_LOST, 0); >>>>>>> - crm_update_peer_expected(__FUNCTION__, peer, >>>>>>> CRMD_JOINSTATE_DOWN); >>>>>>> - crm_update_peer_join(__FUNCTION__, peer, crm_join_none); >>>>>>> + crmd_peer_down(peer, TRUE); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> diff --git a/crmd/utils.c b/crmd/utils.c >>>>>>> index 3988cfe..2df53ab 100644 >>>>>>> --- a/crmd/utils.c >>>>>>> +++ b/crmd/utils.c >>>>>>> @@ -1077,3 +1077,13 @@ update_attrd_remote_node_removed(const char >>>>>>> *host, const char *user_name) >>>>>>> crm_trace("telling attrd to clear attributes for remote host >>>>>>> %s", host); >>>>>>> update_attrd_helper(host, NULL, NULL, user_name, TRUE, 'C'); >>>>>>> } >>>>>>> + >>>>>>> +void crmd_peer_down(crm_node_t *peer, bool full) >>>>>>> +{ >>>>>>> + if(full && peer->state == NULL) { >>>>>>> + crm_update_peer_state(__FUNCTION__, peer, CRM_NODE_LOST, 0); >>>>>>> + crm_update_peer_proc(__FUNCTION__, peer, crm_proc_none, >>>>>>> NULL); >>>>>>> + } >>>>>>> + crm_update_peer_join(__FUNCTION__, peer, crm_join_none); >>>>>>> + crm_update_peer_expected(__FUNCTION__, peer, >>>>>>> CRMD_JOINSTATE_DOWN); >>>>>>> +} >>>>>>> >>>>>>> On 16 Jan 2014, at 7:24 pm, Andrey Groshev <gre...@yandex.ru> wrote: >>>>>>>> 16.01.2014, 01:30, "Andrew Beekhof" <and...@beekhof.net>: >>>>>>>>> On 16 Jan 2014, at 12:41 am, Andrey Groshev <gre...@yandex.ru> >>>>>>>>> wrote: >>>>>>>>>> 15.01.2014, 02:53, "Andrew Beekhof" <and...@beekhof.net>: >>>>>>>>>>> On 15 Jan 2014, at 12:15 am, Andrey Groshev <gre...@yandex.ru> >>>>>>>>>>> wrote: >>>>>>>>>>>> 14.01.2014, 10:00, "Andrey Groshev" <gre...@yandex.ru>: >>>>>>>>>>>>> 14.01.2014, 07:47, "Andrew Beekhof" <and...@beekhof.net>: >>>>>>>>>>>>>> Ok, here's what happens: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. node2 is lost >>>>>>>>>>>>>> 2. fencing of node2 starts >>>>>>>>>>>>>> 3. node2 reboots (and cluster starts) >>>>>>>>>>>>>> 4. node2 returns to the membership >>>>>>>>>>>>>> 5. node2 is marked as a cluster member >>>>>>>>>>>>>> 6. DC tries to bring it into the cluster, but needs to >>>>>>>>>>>>>> cancel the active transition first. >>>>>>>>>>>>>> Which is a problem since the node2 fencing operation >>>>>>>>>>>>>> is part of that >>>>>>>>>>>>>> 7. node2 is in a transition (pending) state until fencing >>>>>>>>>>>>>> passes or fails >>>>>>>>>>>>>> 8a. fencing fails: transition completes and the node >>>>>>>>>>>>>> joins the cluster >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thats in theory, except we automatically try again. Which >>>>>>>>>>>>>> isn't appropriate. >>>>>>>>>>>>>> This should be relatively easy to fix. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 8b. fencing passes: the node is incorrectly marked as >>>>>>>>>>>>>> offline >>>>>>>>>>>>>> >>>>>>>>>>>>>> This I have no idea how to fix yet. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On another note, it doesn't look like this agent works at >>>>>>>>>>>>>> all. >>>>>>>>>>>>>> The node has been back online for a long time and the >>>>>>>>>>>>>> agent is still timing out after 10 minutes. >>>>>>>>>>>>>> So "Once the script makes sure that the victim will >>>>>>>>>>>>>> rebooted and again available via ssh - it exit with 0." does not >>>>>>>>>>>>>> seem true. >>>>>>>>>>>>> Damn. Looks like you're right. At some time I broke my >>>>>>>>>>>>> agent and had not noticed it. Who will understand. >>>>>>>>>>>> I repaired my agent - after send reboot he is wait STDIN. >>>>>>>>>>>> Returned "normally" a behavior - hangs "pending", until >>>>>>>>>>>> manually send reboot. :) >>>>>>>>>>> Right. Now you're in case 8b. >>>>>>>>>>> >>>>>>>>>>> Can you try this patch: >>>>>>>>>>> http://paste.fedoraproject.org/68450/38973966 >>>>>>>>>> Killed all day experiences. >>>>>>>>>> It turns out here that: >>>>>>>>>> 1. Did cluster. >>>>>>>>>> 2. On the node-2 send signal (-4) - killed corosink >>>>>>>>>> 3. From node-1 (there DC) - stonith sent reboot >>>>>>>>>> 4. Noda rebooted and resources start. >>>>>>>>>> 5. Again. On the node-2 send signal (-4) - killed corosink >>>>>>>>>> 6. Again. From node-1 (there DC) - stonith sent reboot >>>>>>>>>> 7. Noda-2 rebooted and hangs in "pending" >>>>>>>>>> 8. Waiting, waiting..... manually reboot. >>>>>>>>>> 9. Noda-2 reboot and raised resources start. >>>>>>>>>> 10. GOTO p.2 >>>>>>>>> Logs? >>>>>>>> Yesterday I wrote an additional letter why not put the logs. >>>>>>>> Read it please, it contains a few more questions. >>>>>>>> Today again began to hang and continue along the same cycle. >>>>>>>> Logs here http://send2me.ru/crmrep2.tar.bz2 >>>>>>>>>>>> New logs: http://send2me.ru/crmrep1.tar.bz2 >>>>>>>>>>>>>> On 14 Jan 2014, at 1:19 pm, Andrew Beekhof >>>>>>>>>>>>>> <and...@beekhof.net> wrote: >>>>>>>>>>>>>>> Apart from anything else, your timeout needs to be >>>>>>>>>>>>>>> bigger: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Jan 13 12:21:36 [17223] >>>>>>>>>>>>>>> dev-cluster2-node1.unix.tensor.ru stonith-ng: ( >>>>>>>>>>>>>>> commands.c:1321 ) error: log_operation: Operation 'reboot' >>>>>>>>>>>>>>> [11331] (call 2 from crmd.17227) for host >>>>>>>>>>>>>>> 'dev-cluster2-node2.unix.tensor.ru' with device 'st1' returned: >>>>>>>>>>>>>>> -62 (Timer expired) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 14 Jan 2014, at 7:18 am, Andrew Beekhof >>>>>>>>>>>>>>> <and...@beekhof.net> wrote: >>>>>>>>>>>>>>>> On 13 Jan 2014, at 8:31 pm, Andrey Groshev >>>>>>>>>>>>>>>> <gre...@yandex.ru> wrote: >>>>>>>>>>>>>>>>> 13.01.2014, 02:51, "Andrew Beekhof" >>>>>>>>>>>>>>>>> <and...@beekhof.net>: >>>>>>>>>>>>>>>>>> On 10 Jan 2014, at 9:55 pm, Andrey Groshev >>>>>>>>>>>>>>>>>> <gre...@yandex.ru> wrote: >>>>>>>>>>>>>>>>>>> 10.01.2014, 14:31, "Andrey Groshev" >>>>>>>>>>>>>>>>>>> <gre...@yandex.ru>: >>>>>>>>>>>>>>>>>>>> 10.01.2014, 14:01, "Andrew Beekhof" >>>>>>>>>>>>>>>>>>>> <and...@beekhof.net>: >>>>>>>>>>>>>>>>>>>>> On 10 Jan 2014, at 5:03 pm, Andrey Groshev >>>>>>>>>>>>>>>>>>>>> <gre...@yandex.ru> wrote: >>>>>>>>>>>>>>>>>>>>>> 10.01.2014, 05:29, "Andrew Beekhof" >>>>>>>>>>>>>>>>>>>>>> <and...@beekhof.net>: >>>>>>>>>>>>>>>>>>>>>>> On 9 Jan 2014, at 11:11 pm, Andrey Groshev >>>>>>>>>>>>>>>>>>>>>>> <gre...@yandex.ru> wrote: >>>>>>>>>>>>>>>>>>>>>>>> 08.01.2014, 06:22, "Andrew Beekhof" >>>>>>>>>>>>>>>>>>>>>>>> <and...@beekhof.net>: >>>>>>>>>>>>>>>>>>>>>>>>> On 29 Nov 2013, at 7:17 pm, Andrey Groshev >>>>>>>>>>>>>>>>>>>>>>>>> <gre...@yandex.ru> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> Hi, ALL. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I'm still trying to cope with the fact >>>>>>>>>>>>>>>>>>>>>>>>>> that after the fence - node hangs in "pending". >>>>>>>>>>>>>>>>>>>>>>>>> Please define "pending". Where did you >>>>>>>>>>>>>>>>>>>>>>>>> see this? >>>>>>>>>>>>>>>>>>>>>>>> In crm_mon: >>>>>>>>>>>>>>>>>>>>>>>> ...... >>>>>>>>>>>>>>>>>>>>>>>> Node dev-cluster2-node2 (172793105): pending >>>>>>>>>>>>>>>>>>>>>>>> ...... >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> The experiment was like this: >>>>>>>>>>>>>>>>>>>>>>>> Four nodes in cluster. >>>>>>>>>>>>>>>>>>>>>>>> On one of them kill corosync or pacemakerd >>>>>>>>>>>>>>>>>>>>>>>> (signal 4 or 6 oк 11). >>>>>>>>>>>>>>>>>>>>>>>> Thereafter, the remaining start it >>>>>>>>>>>>>>>>>>>>>>>> constantly reboot, under various pretexts, "softly >>>>>>>>>>>>>>>>>>>>>>>> whistling", "fly low", "not a cluster member!" ... >>>>>>>>>>>>>>>>>>>>>>>> Then in the log fell out "Too many failures >>>>>>>>>>>>>>>>>>>>>>>> ...." >>>>>>>>>>>>>>>>>>>>>>>> All this time in the status in crm_mon is >>>>>>>>>>>>>>>>>>>>>>>> "pending". >>>>>>>>>>>>>>>>>>>>>>>> Depending on the wind direction changed to >>>>>>>>>>>>>>>>>>>>>>>> "UNCLEAN" >>>>>>>>>>>>>>>>>>>>>>>> Much time has passed and I can not >>>>>>>>>>>>>>>>>>>>>>>> accurately describe the behavior... >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Now I am in the following state: >>>>>>>>>>>>>>>>>>>>>>>> I tried locate the problem. Came here with >>>>>>>>>>>>>>>>>>>>>>>> this. >>>>>>>>>>>>>>>>>>>>>>>> I set big value in property >>>>>>>>>>>>>>>>>>>>>>>> stonith-timeout="600s". >>>>>>>>>>>>>>>>>>>>>>>> And got the following behavior: >>>>>>>>>>>>>>>>>>>>>>>> 1. pkill -4 corosync >>>>>>>>>>>>>>>>>>>>>>>> 2. from node with DC call my fence agent >>>>>>>>>>>>>>>>>>>>>>>> "sshbykey" >>>>>>>>>>>>>>>>>>>>>>>> 3. It sends reboot victim and waits until >>>>>>>>>>>>>>>>>>>>>>>> she comes to life again. >>>>>>>>>>>>>>>>>>>>>>> Hmmm.... what version of pacemaker? >>>>>>>>>>>>>>>>>>>>>>> This sounds like a timing issue that we fixed >>>>>>>>>>>>>>>>>>>>>>> a while back >>>>>>>>>>>>>>>>>>>>>> Was a version 1.1.11 from December 3. >>>>>>>>>>>>>>>>>>>>>> Now try full update and retest. >>>>>>>>>>>>>>>>>>>>> That should be recent enough. Can you create a >>>>>>>>>>>>>>>>>>>>> crm_report the next time you reproduce? >>>>>>>>>>>>>>>>>>>> Of course yes. Little delay.... :) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> ...... >>>>>>>>>>>>>>>>>>>> cc1: warnings being treated as errors >>>>>>>>>>>>>>>>>>>> upstart.c: In function ‘upstart_job_property’: >>>>>>>>>>>>>>>>>>>> upstart.c:264: error: implicit declaration of >>>>>>>>>>>>>>>>>>>> function ‘g_variant_lookup_value’ >>>>>>>>>>>>>>>>>>>> upstart.c:264: error: nested extern declaration of >>>>>>>>>>>>>>>>>>>> ‘g_variant_lookup_value’ >>>>>>>>>>>>>>>>>>>> upstart.c:264: error: assignment makes pointer >>>>>>>>>>>>>>>>>>>> from integer without a cast >>>>>>>>>>>>>>>>>>>> gmake[2]: *** [libcrmservice_la-upstart.lo] Error 1 >>>>>>>>>>>>>>>>>>>> gmake[2]: Leaving directory >>>>>>>>>>>>>>>>>>>> `/root/ha/pacemaker/lib/services' >>>>>>>>>>>>>>>>>>>> make[1]: *** [all-recursive] Error 1 >>>>>>>>>>>>>>>>>>>> make[1]: Leaving directory `/root/ha/pacemaker/lib' >>>>>>>>>>>>>>>>>>>> make: *** [core] Error 1 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I'm trying to solve this a problem. >>>>>>>>>>>>>>>>>>> Do not get solved quickly... >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> https://developer.gnome.org/glib/2.28/glib-GVariant.html#g-variant-lookup-value >>>>>>>>>>>>>>>>>>> g_variant_lookup_value () Since 2.28 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> # yum list installed glib2 >>>>>>>>>>>>>>>>>>> Loaded plugins: fastestmirror, rhnplugin, security >>>>>>>>>>>>>>>>>>> This system is receiving updates from RHN Classic >>>>>>>>>>>>>>>>>>> or Red Hat Satellite. >>>>>>>>>>>>>>>>>>> Loading mirror speeds from cached hostfile >>>>>>>>>>>>>>>>>>> Installed Packages >>>>>>>>>>>>>>>>>>> glib2.x86_64 >>>>>>>>>>>>>>>>>>> 2.26.1-3.el6 >>>>>>>>>>>>>>>>>>> installed >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> # cat /etc/issue >>>>>>>>>>>>>>>>>>> CentOS release 6.5 (Final) >>>>>>>>>>>>>>>>>>> Kernel \r on an \m >>>>>>>>>>>>>>>>>> Can you try this patch? >>>>>>>>>>>>>>>>>> Upstart jobs wont work, but the code will compile >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> diff --git a/lib/services/upstart.c >>>>>>>>>>>>>>>>>> b/lib/services/upstart.c >>>>>>>>>>>>>>>>>> index 831e7cf..195c3a4 100644 >>>>>>>>>>>>>>>>>> --- a/lib/services/upstart.c >>>>>>>>>>>>>>>>>> +++ b/lib/services/upstart.c >>>>>>>>>>>>>>>>>> @@ -231,12 +231,21 @@ upstart_job_exists(const char >>>>>>>>>>>>>>>>>> *name) >>>>>>>>>>>>>>>>>> static char * >>>>>>>>>>>>>>>>>> upstart_job_property(const char *obj, const gchar * >>>>>>>>>>>>>>>>>> iface, const char *name) >>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>> + char *output = NULL; >>>>>>>>>>>>>>>>>> + >>>>>>>>>>>>>>>>>> +#if !GLIB_CHECK_VERSION(2,28,0) >>>>>>>>>>>>>>>>>> + static bool err = TRUE; >>>>>>>>>>>>>>>>>> + >>>>>>>>>>>>>>>>>> + if(err) { >>>>>>>>>>>>>>>>>> + crm_err("This version of glib is too old to >>>>>>>>>>>>>>>>>> support upstart jobs"); >>>>>>>>>>>>>>>>>> + err = FALSE; >>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>> +#else >>>>>>>>>>>>>>>>>> GError *error = NULL; >>>>>>>>>>>>>>>>>> GDBusProxy *proxy; >>>>>>>>>>>>>>>>>> GVariant *asv = NULL; >>>>>>>>>>>>>>>>>> GVariant *value = NULL; >>>>>>>>>>>>>>>>>> GVariant *_ret = NULL; >>>>>>>>>>>>>>>>>> - char *output = NULL; >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> crm_info("Calling GetAll on %s", obj); >>>>>>>>>>>>>>>>>> proxy = get_proxy(obj, BUS_PROPERTY_IFACE); >>>>>>>>>>>>>>>>>> @@ -272,6 +281,7 @@ upstart_job_property(const char >>>>>>>>>>>>>>>>>> *obj, const gchar * iface, const char *name) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> g_object_unref(proxy); >>>>>>>>>>>>>>>>>> g_variant_unref(_ret); >>>>>>>>>>>>>>>>>> +#endif >>>>>>>>>>>>>>>>>> return output; >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> Ok :) I patch source. >>>>>>>>>>>>>>>>> Type "make rc" - the same error. >>>>>>>>>>>>>>>> Because its not building your local changes >>>>>>>>>>>>>>>>> Make new copy via "fetch" - the same error. >>>>>>>>>>>>>>>>> It seems that if not exist >>>>>>>>>>>>>>>>> ClusterLabs-pacemaker-Pacemaker-1.1.11-rc3.tar.gz, then >>>>>>>>>>>>>>>>> download it. >>>>>>>>>>>>>>>>> Otherwise use exist archive. >>>>>>>>>>>>>>>>> Cutted log ....... >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> # make rc >>>>>>>>>>>>>>>>> make TAG=Pacemaker-1.1.11-rc3 rpm >>>>>>>>>>>>>>>>> make[1]: Entering directory `/root/ha/pacemaker' >>>>>>>>>>>>>>>>> rm -f pacemaker-dirty.tar.* pacemaker-tip.tar.* >>>>>>>>>>>>>>>>> pacemaker-HEAD.tar.* >>>>>>>>>>>>>>>>> if [ ! -f >>>>>>>>>>>>>>>>> ClusterLabs-pacemaker-Pacemaker-1.1.11-rc3.tar.gz ]; then >>>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>> rm -f pacemaker.tar.*; >>>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>> if [ Pacemaker-1.1.11-rc3 = dirty ]; then >>>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>> git commit -m "DO-NOT-PUSH" -a; >>>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>> git archive >>>>>>>>>>>>>>>>> --prefix=ClusterLabs-pacemaker-Pacemaker-1.1.11-rc3/ HEAD | >>>>>>>>>>>>>>>>> gzip > ClusterLabs-pacemaker-Pacemaker-1.1.11-rc3.tar.gz; >>>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>> git reset --mixed HEAD^; >>>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>> else >>>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>> git archive >>>>>>>>>>>>>>>>> --prefix=ClusterLabs-pacemaker-Pacemaker-1.1.11-rc3/ >>>>>>>>>>>>>>>>> Pacemaker-1.1.11-rc3 | gzip > >>>>>>>>>>>>>>>>> ClusterLabs-pacemaker-Pacemaker-1.1.11-rc3.tar.gz; \ >>>>>>>>>>>>>>>>> fi; >>>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>> echo `date`: Rebuilt >>>>>>>>>>>>>>>>> ClusterLabs-pacemaker-Pacemaker-1.1.11-rc3.tar.gz; >>>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>> else >>>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>> echo `date`: Using existing tarball: >>>>>>>>>>>>>>>>> ClusterLabs-pacemaker-Pacemaker-1.1.11-rc3.tar.gz; >>>>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>>>> fi >>>>>>>>>>>>>>>>> Mon Jan 13 13:23:21 MSK 2014: Using existing tarball: >>>>>>>>>>>>>>>>> ClusterLabs-pacemaker-Pacemaker-1.1.11-rc3.tar.gz >>>>>>>>>>>>>>>>> ....... >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Well, "make rpm" - build rpms and I create cluster. >>>>>>>>>>>>>>>>> I spent the same tests and confirmed the behavior. >>>>>>>>>>>>>>>>> crm_reoprt log here - http://send2me.ru/crmrep.tar.bz2 >>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>> , >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org >>>>>>>>>>>>>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker >>>>>>>>>>>>>> >>>>>>>>>>>>>> Project Home: http://www.clusterlabs.org >>>>>>>>>>>>>> Getting started: >>>>>>>>>>>>>> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >>>>>>>>>>>>>> Bugs: http://bugs.clusterlabs.org >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org >>>>>>>>>>>>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker >>>>>>>>>>>>> >>>>>>>>>>>>> Project Home: http://www.clusterlabs.org >>>>>>>>>>>>> Getting started: >>>>>>>>>>>>> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >>>>>>>>>>>>> Bugs: http://bugs.clusterlabs.org >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org >>>>>>>>>>>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker >>>>>>>>>>>> >>>>>>>>>>>> Project Home: http://www.clusterlabs.org >>>>>>>>>>>> Getting started: >>>>>>>>>>>> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >>>>>>>>>>>> Bugs: http://bugs.clusterlabs.org >>>>>>>>>>> , >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org >>>>>>>>>>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker >>>>>>>>>>> >>>>>>>>>>> Project Home: http://www.clusterlabs.org >>>>>>>>>>> Getting started: >>>>>>>>>>> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >>>>>>>>>>> Bugs: http://bugs.clusterlabs.org >>>>>>>>>> _______________________________________________ >>>>>>>>>> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org >>>>>>>>>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker >>>>>>>>>> >>>>>>>>>> Project Home: http://www.clusterlabs.org >>>>>>>>>> Getting started: >>>>>>>>>> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >>>>>>>>>> Bugs: http://bugs.clusterlabs.org >>>>>>>>> , >>>>>>>>> _______________________________________________ >>>>>>>>> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org >>>>>>>>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker >>>>>>>>> >>>>>>>>> Project Home: http://www.clusterlabs.org >>>>>>>>> Getting started: >>>>>>>>> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >>>>>>>>> Bugs: http://bugs.clusterlabs.org >>>>>>>> _______________________________________________ >>>>>>>> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org >>>>>>>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker >>>>>>>> >>>>>>>> Project Home: http://www.clusterlabs.org >>>>>>>> Getting started: >>>>>>>> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >>>>>>>> Bugs: http://bugs.clusterlabs.org >>>>>>> , >>>>>>> _______________________________________________ >>>>>>> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org >>>>>>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker >>>>>>> >>>>>>> Project Home: http://www.clusterlabs.org >>>>>>> Getting started: >>>>>>> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >>>>>>> Bugs: http://bugs.clusterlabs.org >>>>>> _______________________________________________ >>>>>> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org >>>>>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker >>>>>> >>>>>> Project Home: http://www.clusterlabs.org >>>>>> Getting started: >>>>>> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >>>>>> Bugs: http://bugs.clusterlabs.org >>>>> , >>>>> _______________________________________________ >>>>> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org >>>>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker >>>>> >>>>> Project Home: http://www.clusterlabs.org >>>>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >>>>> Bugs: http://bugs.clusterlabs.org >>>> _______________________________________________ >>>> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org >>>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker >>>> >>>> Project Home: http://www.clusterlabs.org >>>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >>>> Bugs: http://bugs.clusterlabs.org >>> _______________________________________________ >>> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org >>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker >>> >>> Project Home: http://www.clusterlabs.org >>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >>> Bugs: http://bugs.clusterlabs.org >> >> , >> _______________________________________________ >> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org >> http://oss.clusterlabs.org/mailman/listinfo/pacemaker >> >> Project Home: http://www.clusterlabs.org >> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >> Bugs: http://bugs.clusterlabs.org > > _______________________________________________ > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
