Re: [ClusterLabs] Resource-agents log is not output to /var/log/pacemaker/pacemaker.log on RHEL8
Hi Ken and Jan, Thank you for your comment. I understand that solusion is to set PCMK_logfile in the sysconfig file. As a permanent fix, if you use the default values inside Pacemaker, how about setting environment variables using set_daemon_option() there? For example, as PCMK_logficility does. https://github.com/ClusterLabs/pacemaker/blob/Pacemaker-2.0.2-rc2/lib/common/logging.c#L806 BTW, Pacemaker writes to /var/log/pacemaker/pacemaker.log via libqb. RA writes to this file with echo redirect. If writing occurs at the same time, is there a risk that the file may be corrupted or the written log may disappear? I have never actually had a problem, but I'm interested in how this might happen. Regards, Yusuke 2019年5月28日(火) 23:56 Jan Pokorný : > On 28/05/19 09:29 -0500, Ken Gaillot wrote: > > On Mon, 2019-05-27 at 14:12 +0900, 飯田雄介 wrote: > >> By the way, when /var/log/pacemaker/pacemaker.log is explicitly set > >> in the PCMK_logfile, it is confirmed that the resource-agents log is > >> output to the file set in the PCMK_logfile. > > > > Interesting ... the resource-agents library must look for PCMK_logfile > > as well as HA_logfile. In that case, the easiest solution will be for > > us to set PCMK_logfile explicitly in the shipped sysconfig file. I can > > squeeze that into the soon-to-be-released 2.0.2 since it's not a code > > change. > > Solution remains the same, only meant to note that presence of either: > > PCMK_logfile > HA_logfile (likely on the way towards deprecation, preferably avoid) > > in the environment (from respective sysconfig/default/conf.d file for > pacemaker) will trigger export of HA_LOGFILE environment variable > propagated subsequently towards the agent processes, and everything > then works as expected. IOW. OCF and/or resource-agents are still > reasonably decoupled, thankfully. > > -- > Jan (Poki) > ___ > Manage your subscription: > https://lists.clusterlabs.org/mailman/listinfo/users > > ClusterLabs home: https://www.clusterlabs.org/ -- 株式会社 DNPメトロシステムズ 飯田 雄介（iida...@mail.dnp.co.jp） 〒141-8001 東京都品川区西五反田3-5-20 DNP五反田ビル 携帯. 070-3186-0919 ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
[ClusterLabs] Resource-agents log is not output to /var/log/pacemaker/pacemaker.log on RHEL8
Hi, I am verifying the operation of the cluster with RHEL8. In the verification, I noticed that resource-agents log was not output to /var/log/pacemaker/pacemaker.log. "/etc/sysconfig/pacemaker" is used by default. I know that resource-agents logs are output when passing the HA_logfile environment variable. Pacemaker on RHEL7 has confirmed that this environment variable is set. ``` # cat /proc/$(pidof /usr/libexec/pacemaker/lrmd)/environ | tr '\0' '\n' | sort HA_LOGD=no HA_LOGFACILITY=daemon HA_cluster_type=corosync HA_debug=0 HA_logfacility=daemon HA_logfile=/var/log/cluster/corosync.log HA_mcp=true HA_quorum_type=corosync HA_use_logd=off LANG=ja_JP.UTF-8 LC_ALL=C NOTIFY_SOCKET=/run/systemd/notify PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin PCMK_cluster_type=corosync PCMK_debug=0 PCMK_logfacility=daemon PCMK_logfile=/var/log/cluster/corosync.log PCMK_mcp=true PCMK_quorum_type=corosync PCMK_service=pacemakerd PCMK_use_logd=off PCMK_watchdog=false VALGRIND_OPTS=--leak-check=full --tresource-agentsce-children=no --vgdb=no --num-callers=25 --log-file=/var/lib/pacemaker/valgrind-%p --suppressions=/usr/share/pacemaker/tests/valgrind-pcmk.suppressions --gen-suppressions=all ``` However, it seems that this environment variable is not set in RHEL8. ``` # cat /proc/$(pidof /usr/libexec/pacemaker/pacemaker-execd)/environ | tr '\0' '\n' | sort HA_LOGFACILITY=daemon HA_cluster_type=corosync HA_debug=0 HA_logfacility=daemon HA_mcp=true HA_quorum_type=corosync INVOCATION_ID=6204f0841b814f6c92ea20db02b8ec9e JOURNAL_STREAM=9:1314759 LANG=ja_JP.UTF-8 LC_ALL=C NOTIFY_SOCKET=/run/systemd/notify PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin PCMK_cluster_type=corosync PCMK_debug=0 PCMK_logfacility=daemon PCMK_mcp=true PCMK_quorum_type=corosync PCMK_service=pacemakerd PCMK_watchdog=false SBD_DELAY_START=no SBD_OPTS= SBD_PACEMAKER=yes SBD_STARTMODE=always SBD_TIMEOUT_ACTION=flush,reboot SBD_WATCHDOG_DEV=/dev/watchdog SBD_WATCHDOG_TIMEOUT=5 VALGRIND_OPTS=--leak-check=full --tresource-agentsce-children=no --vgdb=no --num-callers=25 --log-file=/var/lib/pacemaker/valgrind-%p --suppressions=/usr/share/pacemaker/tests/valgrind-pcmk.suppressions --gen-suppressions=all ``` Is this the intended behavior? By the way, when /var/log/pacemaker/pacemaker.log is explicitly set in the PCMK_logfile, it is confirmed that the resource-agents log is output to the file set in the PCMK_logfile. Regards, Yusuke ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] How can I prevent multiple start of IPaddr 2 in an environment using fence_mpath?
Hi, Ken Thanks for your comment. Network fencing that's a valid means, I also think. However, I think that the reliance on equipment is strong. Since we do not have an SNMP-capable network switch in our environment, we can not immediately try it. Thanks, Yusuke > -Original Message- > From: Users [mailto:users-boun...@clusterlabs.org] On Behalf Of Ken Gaillot > Sent: Friday, April 06, 2018 11:12 PM > To: Cluster Labs - All topics related to open-source clustering welcomed > Subject: Re: [ClusterLabs] How can I prevent multiple start of IPaddr 2 in an > environment using fence_mpath? > > On Fri, 2018-04-06 at 04:30 +, 飯田 雄介 wrote: > > Hi, all > > I am testing the environment using fence_mpath with the following > > settings. > > > > === > > Stack: corosync > > Current DC: x3650f (version 1.1.17-1.el7-b36b869) - partition with > > quorum > > Last updated: Fri Apr 6 13:16:20 2018 > > Last change: Thu Mar 1 18:38:02 2018 by root via cibadmin on x3650e > > > > 2 nodes configured > > 13 resources configured > > > > Online: [ x3650e x3650f ] > > > > Full list of resources: > > > > fenceMpath-x3650e(stonith:fence_mpath): Started x3650e > > fenceMpath-x3650f(stonith:fence_mpath): Started x3650f > > Resource Group: grpPostgreSQLDB > > prmFsPostgreSQLDB1 (ocf::heartbeat:Filesystem):Start > > ed x3650e > > prmFsPostgreSQLDB2 (ocf::heartbeat:Filesystem):Start > > ed x3650e > > prmFsPostgreSQLDB3 (ocf::heartbeat:Filesystem):Start > > ed x3650e > > prmApPostgreSQLDB(ocf::heartbeat:pgsql): Started x3650e > > Resource Group: grpPostgreSQLIP > > prmIpPostgreSQLDB(ocf::heartbeat:IPaddr2): Start > > ed x3650e > > Clone Set: clnDiskd1 [prmDiskd1] > > Started: [ x3650e x3650f ] > > Clone Set: clnDiskd2 [prmDiskd2] > > Started: [ x3650e x3650f ] > > Clone Set: clnPing [prmPing] > > Started: [ x3650e x3650f ] > > === > > > > When split-brain occurs in this environment, x3650f executes fence and > > the resource is started with x3650f. > > > > === view of x3650e > > Stack: corosync > > Current DC: x3650e (version 1.1.17-1.el7-b36b869) - partition > > WITHOUT quorum > > Last updated: Fri Apr 6 13:16:36 2018 > > Last change: Thu Mar 1 18:38:02 2018 by root via cibadmin on x3650e > > > > 2 nodes configured > > 13 resources configured > > > > Node x3650f: UNCLEAN (offline) > > Online: [ x3650e ] > > > > Full list of resources: > > > > fenceMpath-x3650e(stonith:fence_mpath): Started x3650e > > fenceMpath-x3650f(stonith:fence_mpath): Started[ x3650e x3650f > > ] > > Resource Group: grpPostgreSQLDB > > prmFsPostgreSQLDB1 (ocf::heartbeat:Filesystem):Start > > ed x3650e > > prmFsPostgreSQLDB2 (ocf::heartbeat:Filesystem):Start > > ed x3650e > > prmFsPostgreSQLDB3 (ocf::heartbeat:Filesystem):Start > > ed x3650e > > prmApPostgreSQLDB(ocf::heartbeat:pgsql): Started x3650e > > Resource Group: grpPostgreSQLIP > > prmIpPostgreSQLDB(ocf::heartbeat:IPaddr2): Start > > ed x3650e > > Clone Set: clnDiskd1 [prmDiskd1] > > prmDiskd1(ocf::pacemaker:diskd): Started x3650f > > (UNCLEAN) > > Started: [ x3650e ] > > Clone Set: clnDiskd2 [prmDiskd2] > > prmDiskd2(ocf::pacemaker:diskd): Started x3650f > > (UNCLEAN) > > Started: [ x3650e ] > > Clone Set: clnPing [prmPing] > > prmPing (ocf::pacemaker:ping): Started x3650f (UNCLEAN) > > Started: [ x3650e ] > > > > === view of x3650f > > Stack: corosync > > Current DC: x3650f (version 1.1.17-1.el7-b36b869) - partition > > WITHOUT quorum > > Last updated: Fri Apr 6 13:16:36 2018 > > Last change: Thu Mar 1 18:38:02 2018 by root via cibadmin on x3650e > > > > 2 nodes configured > > 13 resources configured > > > > Online: [ x3650f ] > > OFFLINE: [ x3650e ] > > > > Full list of resources: > > > > fenceMpath-x3650e(stonith:fence_mpath): Started x3650f > > fenceMpath-x3650f(stonith:fence_mpath): Started x3650f > > Resource Group: grpPostgreSQLDB > > prmFsPostgreSQLDB1 (ocf::heartbeat:Filesystem):Start > > ed x3650f > > prmFsPostgreS
Re: [ClusterLabs] How can I prevent multiple start of IPaddr 2 in an environment using fence_mpath?
Hi, Andrei Thanks for your comment. We are not assuming node level fencing in the current environment. I tried the power_timeout setting that you taught. However, fence_mpath immediately returns the status off when you execute the off action. https://github.com/ClusterLabs/fence-agents/blob/v4.0.25/fence/agents/lib/fencing.py.py#L744 Therefore, we could not wait to stop IPaddr2 using this option. I read the code and learned the power_wait option. With this option you can delay the completion of STONITH by the specified amount of time, so it seems to meet our requirements. Thanks, Yusuke > -Original Message- > From: Users [mailto:users-boun...@clusterlabs.org] On Behalf Of Andrei > Borzenkov > Sent: Friday, April 06, 2018 2:04 PM > To: users@clusterlabs.org > Subject: Re: [ClusterLabs] How can I prevent multiple start of IPaddr 2 in an > environment using fence_mpath? > > 06.04.2018 07:30, 飯田 雄介 пишет: > > Hi, all > > I am testing the environment using fence_mpath with the following settings. > > > > === > > Stack: corosync > > Current DC: x3650f (version 1.1.17-1.el7-b36b869) - partition with quorum > > Last updated: Fri Apr 6 13:16:20 2018 > > Last change: Thu Mar 1 18:38:02 2018 by root via cibadmin on x3650e > > > > 2 nodes configured > > 13 resources configured > > > > Online: [ x3650e x3650f ] > > > > Full list of resources: > > > >fenceMpath-x3650e(stonith:fence_mpath): Started x3650e > >fenceMpath-x3650f(stonith:fence_mpath): Started x3650f > >Resource Group: grpPostgreSQLDB > >prmFsPostgreSQLDB1 (ocf::heartbeat:Filesystem):Started > x3650e > >prmFsPostgreSQLDB2 (ocf::heartbeat:Filesystem):Started > x3650e > >prmFsPostgreSQLDB3 (ocf::heartbeat:Filesystem):Started > x3650e > >prmApPostgreSQLDB(ocf::heartbeat:pgsql): Started x3650e > >Resource Group: grpPostgreSQLIP > >prmIpPostgreSQLDB(ocf::heartbeat:IPaddr2): Started > x3650e > >Clone Set: clnDiskd1 [prmDiskd1] > >Started: [ x3650e x3650f ] > >Clone Set: clnDiskd2 [prmDiskd2] > >Started: [ x3650e x3650f ] > >Clone Set: clnPing [prmPing] > >Started: [ x3650e x3650f ] > > === > > > > When split-brain occurs in this environment, x3650f executes fence and the > resource is started with x3650f. > > > > === view of x3650e > > Stack: corosync > > Current DC: x3650e (version 1.1.17-1.el7-b36b869) - partition WITHOUT > quorum > > Last updated: Fri Apr 6 13:16:36 2018 > > Last change: Thu Mar 1 18:38:02 2018 by root via cibadmin on x3650e > > > > 2 nodes configured > > 13 resources configured > > > > Node x3650f: UNCLEAN (offline) > > Online: [ x3650e ] > > > > Full list of resources: > > > >fenceMpath-x3650e(stonith:fence_mpath): Started x3650e > >fenceMpath-x3650f(stonith:fence_mpath): Started[ x3650e x3650f ] > >Resource Group: grpPostgreSQLDB > >prmFsPostgreSQLDB1 (ocf::heartbeat:Filesystem):Started > x3650e > >prmFsPostgreSQLDB2 (ocf::heartbeat:Filesystem):Started > x3650e > >prmFsPostgreSQLDB3 (ocf::heartbeat:Filesystem):Started > x3650e > >prmApPostgreSQLDB(ocf::heartbeat:pgsql): Started x3650e > >Resource Group: grpPostgreSQLIP > >prmIpPostgreSQLDB(ocf::heartbeat:IPaddr2): Started > x3650e > >Clone Set: clnDiskd1 [prmDiskd1] > >prmDiskd1(ocf::pacemaker:diskd): Started x3650f (UNCLEAN) > >Started: [ x3650e ] > >Clone Set: clnDiskd2 [prmDiskd2] > >prmDiskd2(ocf::pacemaker:diskd): Started x3650f (UNCLEAN) > >Started: [ x3650e ] > >Clone Set: clnPing [prmPing] > >prmPing (ocf::pacemaker:ping): Started x3650f (UNCLEAN) > >Started: [ x3650e ] > > > > === view of x3650f > > Stack: corosync > > Current DC: x3650f (version 1.1.17-1.el7-b36b869) - partition WITHOUT > quorum > > Last updated: Fri Apr 6 13:16:36 2018 > > Last change: Thu Mar 1 18:38:02 2018 by root via cibadmin on x3650e > > > > 2 nodes configured > > 13 resources configured > > > > Online: [ x3650f ] > > OFFLINE: [ x3650e ] > > > > Full list of resources: > > > >fenceMpath-x3650e(stonith:fence_mpath): Started x3650f > >fenceMpath-x3650f(stonith:fence_mpath): Started x365
[ClusterLabs] How can I prevent multiple start of IPaddr 2 in an environment using fence_mpath?
Hi, all I am testing the environment using fence_mpath with the following settings. === Stack: corosync Current DC: x3650f (version 1.1.17-1.el7-b36b869) - partition with quorum Last updated: Fri Apr 6 13:16:20 2018 Last change: Thu Mar 1 18:38:02 2018 by root via cibadmin on x3650e 2 nodes configured 13 resources configured Online: [ x3650e x3650f ] Full list of resources: fenceMpath-x3650e(stonith:fence_mpath): Started x3650e fenceMpath-x3650f(stonith:fence_mpath): Started x3650f Resource Group: grpPostgreSQLDB prmFsPostgreSQLDB1 (ocf::heartbeat:Filesystem):Started x3650e prmFsPostgreSQLDB2 (ocf::heartbeat:Filesystem):Started x3650e prmFsPostgreSQLDB3 (ocf::heartbeat:Filesystem):Started x3650e prmApPostgreSQLDB(ocf::heartbeat:pgsql): Started x3650e Resource Group: grpPostgreSQLIP prmIpPostgreSQLDB(ocf::heartbeat:IPaddr2): Started x3650e Clone Set: clnDiskd1 [prmDiskd1] Started: [ x3650e x3650f ] Clone Set: clnDiskd2 [prmDiskd2] Started: [ x3650e x3650f ] Clone Set: clnPing [prmPing] Started: [ x3650e x3650f ] === When split-brain occurs in this environment, x3650f executes fence and the resource is started with x3650f. === view of x3650e Stack: corosync Current DC: x3650e (version 1.1.17-1.el7-b36b869) - partition WITHOUT quorum Last updated: Fri Apr 6 13:16:36 2018 Last change: Thu Mar 1 18:38:02 2018 by root via cibadmin on x3650e 2 nodes configured 13 resources configured Node x3650f: UNCLEAN (offline) Online: [ x3650e ] Full list of resources: fenceMpath-x3650e(stonith:fence_mpath): Started x3650e fenceMpath-x3650f(stonith:fence_mpath): Started[ x3650e x3650f ] Resource Group: grpPostgreSQLDB prmFsPostgreSQLDB1 (ocf::heartbeat:Filesystem):Started x3650e prmFsPostgreSQLDB2 (ocf::heartbeat:Filesystem):Started x3650e prmFsPostgreSQLDB3 (ocf::heartbeat:Filesystem):Started x3650e prmApPostgreSQLDB(ocf::heartbeat:pgsql): Started x3650e Resource Group: grpPostgreSQLIP prmIpPostgreSQLDB(ocf::heartbeat:IPaddr2): Started x3650e Clone Set: clnDiskd1 [prmDiskd1] prmDiskd1(ocf::pacemaker:diskd): Started x3650f (UNCLEAN) Started: [ x3650e ] Clone Set: clnDiskd2 [prmDiskd2] prmDiskd2(ocf::pacemaker:diskd): Started x3650f (UNCLEAN) Started: [ x3650e ] Clone Set: clnPing [prmPing] prmPing (ocf::pacemaker:ping): Started x3650f (UNCLEAN) Started: [ x3650e ] === view of x3650f Stack: corosync Current DC: x3650f (version 1.1.17-1.el7-b36b869) - partition WITHOUT quorum Last updated: Fri Apr 6 13:16:36 2018 Last change: Thu Mar 1 18:38:02 2018 by root via cibadmin on x3650e 2 nodes configured 13 resources configured Online: [ x3650f ] OFFLINE: [ x3650e ] Full list of resources: fenceMpath-x3650e(stonith:fence_mpath): Started x3650f fenceMpath-x3650f(stonith:fence_mpath): Started x3650f Resource Group: grpPostgreSQLDB prmFsPostgreSQLDB1 (ocf::heartbeat:Filesystem):Started x3650f prmFsPostgreSQLDB2 (ocf::heartbeat:Filesystem):Started x3650f prmFsPostgreSQLDB3 (ocf::heartbeat:Filesystem):Started x3650f prmApPostgreSQLDB(ocf::heartbeat:pgsql): Started x3650f Resource Group: grpPostgreSQLIP prmIpPostgreSQLDB(ocf::heartbeat:IPaddr2): Started x3650f Clone Set: clnDiskd1 [prmDiskd1] Started: [ x3650f ] Stopped: [ x3650e ] Clone Set: clnDiskd2 [prmDiskd2] Started: [ x3650f ] Stopped: [ x3650e ] Clone Set: clnPing [prmPing] Started: [ x3650f ] Stopped: [ x3650e ] === However, IPaddr2 of x3650e will not stop until pgsql monitor error occurs. At this time, IPaddr2 is temporarily started on two nodes. === view of after pgsql monitor error === Stack: corosync Current DC: x3650e (version 1.1.17-1.el7-b36b869) - partition WITHOUT quorum Last updated: Fri Apr 6 13:16:56 2018 Last change: Thu Mar 1 18:38:02 2018 by root via cibadmin on x3650e 2 nodes configured 13 resources configured Node x3650f: UNCLEAN (offline) Online: [ x3650e ] Full list of resources: fenceMpath-x3650e(stonith:fence_mpath): Started x3650e fenceMpath-x3650f(stonith:fence_mpath): Started[ x3650e x3650f ] Resource Group: grpPostgreSQLDB prmFsPostgreSQLDB1 (ocf::heartbeat:Filesystem):Started x3650e prmFsPostgreSQLDB2 (ocf::heartbeat:Filesystem):Started x3650e prmFsPostgreSQLDB3 (ocf::heartbeat:Filesystem):Started x3650e prmApPostgreSQLDB(ocf::heartbeat:pgsql): Stopped Resource Group: grpPostgreSQLIP prmIpPostgreSQLDB(ocf::heartbeat:IPaddr2): Stopped Clone Set: clnDiskd1 [p
Re: [ClusterLabs] IPaddr2, interval between unsolicited ARP packets
Hi, Hamaguchi-san send_arp exists in two versions depending on the environment. https://github.com/ClusterLabs/resource-agents/blob/master/tools/send_arp.libnet.c https://github.com/ClusterLabs/resource-agents/blob/master/tools/send_arp.linux.c Those that contain in your environment, it seems that it is send_arp.linux.c. send_arp.linux.c has been made to also work with the same options as the send_arp.libnet.c. However, -i and -p In send_arp.linux.c is not used. send_arp.linux.c sends arp every second because it is driven by the alarm(1). https://github.com/ClusterLabs/resource-agents/blob/master/tools/send_arp.linux.c#L384 This interval cannot be changed because they are hard-coded. Regards, Yusuke > -Original Message- > From: Shinjiro Hamaguchi [mailto:hamagu...@agile.ne.jp] > Sent: Wednesday, October 05, 2016 1:57 PM > To: users@clusterlabs.org > Subject: Re: [ClusterLabs] IPaddr2, interval between unsolicited ARP packets > > Matsushima-san > > > Thank you very much for your reply. > And sorry for late reply. > > > >Do you get same result by executing the command manually with different > parameters like this? > I tried following command but same result (1sec interval) > > [command used to send unsolicited arp] > /usr/libexec/heartbeat/send_arp -i 1500 -r 8 eth0 192.168.12.215 auto not_used > not_used > > [result of tcudump] > 04:31:50.475928 ARP, Request who-has 192.168.12.215 (Broadcast) tell > 192.168.12.215, length 28 > 04:31:51.476053 ARP, Request who-has 192.168.12.215 (Broadcast) tell > 192.168.12.215, length 28 > 04:31:52.476146 ARP, Request who-has 192.168.12.215 (Broadcast) tell > 192.168.12.215, length 28 > 04:31:53.476246 ARP, Request who-has 192.168.12.215 (Broadcast) tell > 192.168.12.215, length 28 > 04:31:54.476287 ARP, Request who-has 192.168.12.215 (Broadcast) tell > 192.168.12.215, length 28 > 04:31:55.476406 ARP, Request who-has 192.168.12.215 (Broadcast) tell > 192.168.12.215, length 28 > 04:31:56.476448 ARP, Request who-has 192.168.12.215 (Broadcast) tell > 192.168.12.215, length 28 > 04:31:57.476572 ARP, Request who-has 192.168.12.215 (Broadcast) tell > 192.168.12.215, length 28 > > >Please also make sure the PID file has been created properly. > When I checked manually with send_arp command, I didn't use send_arp command > with "-p" option. > > Even when I did fail-over of IPaddr2resource (not manually execute send_arp > command), I couldn't see pid file generated at /var/run/resource-agents/. > I used following command to see if pid file generated. > > watch -n0.1 "ls -la /var/run/resource-agents/" > > > Thank you in advance. > > > On Wed, Oct 5, 2016 at 12:20 PM, Digimer wrote: > > > > > > Forwarded Message > Subject: Re: [ClusterLabs] IPaddr2, interval between unsolicited ARP > packets > Date: Tue, 4 Oct 2016 11:18:37 +0900 > From: Takehiro Matsushima > Reply-To: Cluster Labs - All topics related to open-source clustering > welcomed > To: Cluster Labs - All topics related to open-source clustering welcomed > > > Hello Hamaguchi-san, > > Do you get same result by executing the command manually with > different parameters like this? > #/usr/libexec/heartbeat/send_arp -i 1500 -r 8 -p > /var/run/resource-agents/send_arp-192.168.12.215 eth0 > 192.168.12.215 > auto not_used not_used > > Please also make sure the PID file has been created properly. > > Thank you, > > Takehiro MATSUSHIMA > > 2016-10-03 14:45 GMT+09:00 Shinjiro Hamaguchi > : > > Hello everyone!! > > > > > > I'm using IPaddr2 for VIP. > > > > In the IPaddr2 document, it say interval between unsolicited ARP > packets is > > default 200msec and can change it using option "-i", but when i check > with > > tcpdump, it looks like sending arp every 1000msec fixed. > > > > Does someone have any idea ? > > > > Thank you in advance. > > > > > > [environment] > > kvm, centOS 6.8 > > pacemaker-1.1.14-8.el6_8.1.x86_64 > > cman-3.0.12.1-78.el6.x86_64 > > resource-agents-3.9.5-34.el6_8.2.x86_64 > > > > > > [command used to send unsolicited arp] > > NOTE: i got this command from /var/log/cluster/corosync.log > > #/usr/libexec/heartbeat/send_arp -i 200 -r 5 -p > > /var/run/resource-agents/send_arp-192.168.12.215 eth0 > 192.168.12.215 auto > > not_used not_used > > > > [result of tcudump] > > > > #tcpdump arp > > > > tcpdump: verbose output suppressed, use -v or -vv for full protocol > decode > > > > listening on eth0, link-type EN10MB (Ethernet), capture size 65535 > bytes > > > > 05:28:17.267296 ARP, Request who-has 192.168.12.215 (Broadcast) tell > > 192.168.12.215, length 28 > > > > 05:28:18.267519 ARP, Request who-has 192.168.12.215 (B
[ClusterLabs] DC of the election will be an infinite loop.
Hi, all I added two lines to comment on cib.xml using crmsh. === # cat test.crm node 167772452: test-3 # comment line 1 # comment line 2 property cib-bootstrap-options: \ have-watchdog=false \ dc-version=1.1.14-1.el7-70404b0 \ cluster-infrastructure=corosync === And was re-start the cluster, the election of the DC was to an infinite loop. Environment We are using the Pacemaker-1.1.14. Where I tried to look at the log, It looks like the handling of the comment node is not good. It looks like the problem occurs when there are two or more lines of comment. Problem seems to occur on or after modification of the following. https://github.com/ClusterLabs/pacemaker/commit/1073786ec24f3bbf26a0f6a5b0614a65edac4301 Does this behavior is a known bug? I will attach a crm_report of when the problem occurred. https://github.com/yuusuke/pcmk_report/blob/master/pcmk-Tue-28-Jun-2016.tar..bz2?raw=true Regards, Yusuke -- Metro Systems Co.,Ltd. Yusuke Iida Mail: iiday...@intellilink.co.jp ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] "After = syslog.service" it is not working?
Hi, Ken I have to get the log. shutdown the -r now ran to "03:00:22". rsyslog also "03:00:22" to receive a TERM appears to have stopped. Regards, Yusuke > -Original Message- > From: Ken Gaillot [mailto:kgail...@redhat.com] > Sent: Friday, January 29, 2016 12:16 AM > To: users@clusterlabs.org > Subject: Re: [ClusterLabs] "After = syslog.service" it is not working? > > On 01/28/2016 12:48 AM, 飯田 雄介 wrote: > > Hi, All > > > > I am building a cluster in the following environments. > > RHEL7.2 > > Pacemaker-1.1.14 > > > > The OS while it is running the Pacemaker was allowed to shutdown. > > Logs at this time Pacemaker in the stop was not output to the syslog. > > > > This "After = syslog.service" does not work is set to start-up script, it > seems pacemaker and rsyslog is stopped at the same time. > > > > Because I think it's rsyslog.service In RHEL7, whether this setting should > not be the "After = rsyslog.service"? > > > > Regards, Yusuke > > The "After = syslog.service" line neither helps nor hurts, and we should just > take it out. > > For a long time (and certainly in RHEL 7's systemd version 219), systemd > automatically orders the system log to start before and stop after other > services, > so I don't think that's the cause of your problem. > > I'm not sure what would cause that behavior; can you post the messages that > are logged once shutdown is initiated? > > ___ > Users mailing list: Users@clusterlabs.org > http://clusterlabs.org/mailman/listinfo/users > > Project Home: http://www.clusterlabs.org Getting started: > http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org pcmk_report.tar.bz2 Description: pcmk_report.tar.bz2 ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
[ClusterLabs] "After = syslog.service" it is not working?
Hi, All I am building a cluster in the following environments. RHEL7.2 Pacemaker-1.1.14 The OS while it is running the Pacemaker was allowed to shutdown. Logs at this time Pacemaker in the stop was not output to the syslog. This "After = syslog.service" does not work is set to start-up script, it seems pacemaker and rsyslog is stopped at the same time. Because I think it's rsyslog.service In RHEL7, whether this setting should not be the "After = rsyslog.service"? Regards, Yusuke -- METRO SYSTEMS CO., LTD Yuusuke Iida Mail: iiday...@intellilink.co.jp ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
