[Ubuntu-ha] [Bug 1890314] Re: RFE HAProxy 2.2 for groovy
*** This bug is a duplicate of bug 1892871 *** https://bugs.launchpad.net/bugs/1892871 ** This bug has been marked a duplicate of bug 1892871 haproxy needs merge with debian experimental 2.2 (LTS version) -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to haproxy in Ubuntu. https://bugs.launchpad.net/bugs/1890314 Title: RFE HAProxy 2.2 for groovy Status in haproxy package in Ubuntu: Triaged Bug description: Is there any chance of getting HAProxy 2.2.x (LTS) into the 20.10 groovy release? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1890314/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1892871] Re: haproxy needs merge with debian experimental 2.2 (LTS version)
This bug was fixed in the package haproxy - 2.2.2-1
---
haproxy (2.2.2-1) experimental; urgency=medium
* New upstream version.
- BUG/MAJOR: dns: don't treat Authority records as an error
- BUG/MAJOR: dns: fix null pointer dereference in
snr_update_srv_status
-- Vincent Bernat Sat, 01 Aug 2020 17:06:42 +0200
haproxy (2.2.1-1) experimental; urgency=medium
* New upstream version.
- BUG/MAJOR: tasks: don't requeue global tasks into the local
queue
- BUG/MAJOR: dns: Make the do-resolve action thread-safe
-- Vincent Bernat Thu, 23 Jul 2020 13:39:14 +0200
haproxy (2.2.0-1) experimental; urgency=medium
* New upstream version.
* Upload to experimental
* Update d/watch to look for 2.2 stable releases
* d/gbp.conf: set branch names for 2.2
* d/patches: refresh patches
-- Vincent Bernat Tue, 14 Jul 2020 16:53:23 +0200
haproxy (2.1.7-1) experimental; urgency=medium
* New upstream version.
-- Vincent Bernat Fri, 12 Jun 2020 07:50:48 +0200
haproxy (2.1.5-1) experimental; urgency=medium
* New upstream version.
- BUG/MAJOR: mux-fcgi: Stop sending loop if FCGI stream is blocked for
any reason
- Revert "BUG/MINOR: connection: always send address-less LOCAL PROXY
connections"
- Revert "BUG/MINOR: connection: make sure to correctly tag local
PROXY connections"
-- Vincent Bernat Mon, 01 Jun 2020 08:52:56 +0200
haproxy (2.1.4-1) experimental; urgency=medium
* New upstream version.
- BUG/CRITICAL: hpack: never index a header into the headroom after
wrapping
- BUG/MAJOR: http-ana: Always abort the request when a tarpit is
triggered
- BUG/MAJOR: list: fix invalid element address calculation
- BUG/MAJOR: proxy_protocol: Properly validate TLV lengths
* d/control: fix maintainer address. Closes: #93.
-- Vincent Bernat Sun, 12 Apr 2020 13:29:54 +0200
haproxy (2.1.3-3) experimental; urgency=medium
* d/copryight: document OpenSSL exception. Closes: #951782.
* d/haproxy.cfg: use "ssl-min-ver" to set minimum version.
* d/patches: fix an overflow in HTTP/2 header handling.
Fix CVE-2020-11100.
-- Vincent Bernat Wed, 01 Apr 2020 21:18:57 +0200
haproxy (2.1.3-2) experimental; urgency=medium
* d/dconv: use Python 3 to build the documentation.
Closes: #948296, #950435.
* d/dconv: replace cgi.escape by html.escape. Closes: #951416.
-- Vincent Bernat Wed, 19 Feb 2020 07:53:53 +0100
haproxy (2.1.3-1) experimental; urgency=medium
* New upstream version.
- BUG/MAJOR: hashes: fix the signedness of the hash inputs
- BUG/MAJOR: memory: Don't forget to unlock the rwlock if the pool is
empty.
-- Vincent Bernat Mon, 20 Jan 2020 06:53:23 +0100
haproxy (2.1.2-1) experimental; urgency=medium
* New upstream version 2.1.2.
- BUG/MAJOR: task: add a new TASK_SHARED_WQ flag to fix foreign requeuing
* d/logrotate.conf: use rsyslog helper instead of SysV init script.
Closes: #946973.
-- Vincent Bernat Fri, 20 Dec 2019 08:20:33 +0100
haproxy (2.1.1-1) experimental; urgency=medium
* New upstream version 2.1.1.
- BUG/MAJOR: dns: add minimalist error processing on the Rx path
-- Vincent Bernat Sat, 14 Dec 2019 11:20:32 +0100
haproxy (2.1.0-2) experimental; urgency=medium
* Link against libatomic on riscv64
-- Apollon Oikonomopoulos Fri, 29 Nov 2019
14:03:49 +0200
haproxy (2.1.0-1) experimental; urgency=medium
* New upstream version 2.1.0
* Upload to experimental
* Update d/watch to look for 2.1 stable releases
* d/gbp.conf: set branch names for 2.1
* Bump Standards-Version to 4.4.1; no changes needed
* Bump dh compat level to 12
+ B-D on debhelper-compat and remove debian/compat
+ Override dh_installsystemd with the same args as dh_installinit
+ Add ${misc:Pre-Depends} to haproxy's Pre-Depends
-- Apollon Oikonomopoulos Wed, 27 Nov 2019
23:30:30 +0200
** Changed in: haproxy (Ubuntu)
Status: In Progress => Fix Released
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-11100
** Changed in: haproxy (Ubuntu)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed to haproxy in Ubuntu.
https://bugs.launchpad.net/bugs/1892871
Title:
haproxy needs merge with debian experimental 2.2 (LTS version)
Status in haproxy package in Ubuntu:
Fix Released
Bug description:
Currently Debian experimental is at "2025-Q2 (LTS)" which is the LTS
version for HAPROXY. We should merge this version sooner than later in
the LTS cycles.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1892871/+subscriptions
___
Mailing list: https:/
[Ubuntu-ha] [Bug 1892871] [NEW] haproxy needs merge with debian experimental 2.2 (LTS version)
Public bug reported: Currently Debian experimental is at "2025-Q2 (LTS)" which is the LTS version for HAPROXY. We should merge this version sooner than later in the LTS cycles. ** Affects: haproxy (Ubuntu) Importance: Medium Assignee: Rafael David Tinoco (rafaeldtinoco) Status: Fix Released ** Changed in: haproxy (Ubuntu) Status: New => In Progress ** Changed in: haproxy (Ubuntu) Importance: Undecided => Medium ** Changed in: haproxy (Ubuntu) Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco) -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to haproxy in Ubuntu. https://bugs.launchpad.net/bugs/1892871 Title: haproxy needs merge with debian experimental 2.2 (LTS version) Status in haproxy package in Ubuntu: Fix Released Bug description: Currently Debian experimental is at "2025-Q2 (LTS)" which is the LTS version for HAPROXY. We should merge this version sooner than later in the LTS cycles. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1892871/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1890491] Re: A pacemaker node fails monitor (probe) and stop /start operations on a resource because it returns "rc=189
Thanks for taking care of this Jorge. Let me know whenever you have a fix ready for this. Cheers! -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1890491 Title: A pacemaker node fails monitor (probe) and stop /start operations on a resource because it returns "rc=189 Status in pacemaker package in Ubuntu: Fix Released Status in pacemaker source package in Bionic: In Progress Status in pacemaker source package in Focal: Fix Released Status in pacemaker source package in Groovy: Fix Released Bug description: Cause: Pacemaker implicitly ordered all stops needed on a Pacemaker Remote node before the stop of the node's Pacemaker Remote connection, including stops that were implied by fencing of the node. Also, Pacemaker scheduled actions on Pacemaker Remote nodes with a failed connection so that the actions could be done once the connection is recovered, even if the connection wasn't being recovered (for example, if the node was shutting down when the failure occurred). Consequence: If a Pacemaker Remote node needed to be fenced while it was in the process of shutting down, once the fencing completed pacemaker scheduled probes on the node. The probes fail because the connection is not actually active. Due to the failed probe, a stop is scheduled which also fails, leading to fencing of the node again, and the situation repeats itself indefinitely. Fix: Pacemaker Remote connection stops are no longer ordered after implied stops, and actions are not scheduled on Pacemaker Remote nodes when the connection is failed and not being started again. Result: A Pacemaker Remote node that needs to be fenced while it is in the process of shutting down is fenced once, without repeating indefinitely. The fix seems to be fixed in pacemaker-1.1.21-1.el7 Related to https://bugzilla.redhat.com/show_bug.cgi?id=1704870 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1890491/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1890185] Re: scheduler: support/backport on-fail="demote" recovery policy for promoted resources
Forwarded Message Subject: [ClusterLabs] Coming in Pacemaker 2.0.5: on-fail=demote / no-quorum-policy=demote Date: Mon, 10 Aug 2020 11:47:24 -0500 From: Ken Gaillot Reply-To: Cluster Labs - All topics related to open-source clustering welcomed Organization: Red Hat To: Cluster Labs - All topics related to open-source clustering welcomed Hi all, Looking ahead to the Pacemaker 2.0.5 release expected at the end of this year, here is a new feature already in the master branch. When configuring resource operations, Pacemaker lets you set an "on- fail" policy to specify whether to restart the resource, fence the node, etc., if the operation fails. With 2.0.5, a new possible value will be "demote", which will mean "demote this resource but do not fully restart it". "Demote" will be a valid value only for promote actions, and for recurring monitors with "role" set to "Master". Once the resource is demoted, it will be eligible for promotion again, so if the promotion scores have not changed, a promote on the same node may be attempted. If this is not desired, the agent can change the promotion scores either in the failed monitor or the demote. The intended use case is an application where a successful demote assures a well-functioning service, and a full restart would be unnecessarily heavyweight. A large database might be an example. Similarly, Pacemaker offers the cluster-wide "no-quorum-policy" option to specify what happens to resources when quorum is lost (the default being to stop them). With 2.0.5, "demote" will be a possible value here as well, and will mean "demote all promotable resources and stop all other resources". The intended use case is an application that cannot cause any harm after being demoted, and may be useful in a demoted role even if there is no quorum. A database that operates read-only when demoted and doesn't depend on any non-promotable resources might be an example. Happy clustering :) -- Ken Gaillot -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1890185 Title: scheduler: support/backport on-fail="demote" recovery policy for promoted resources Status in pacemaker package in Ubuntu: Triaged Status in pacemaker source package in Bionic: Won't Fix Status in pacemaker source package in Eoan: Won't Fix Status in pacemaker source package in Focal: Triaged Bug description: There is a request for the feature: Feature: scheduler: new on-fail="demote" recovery policy for promoted… to be backported to Ubuntu LTS versions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1890185/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1890314] Re: RFE HAProxy 2.2 for groovy
Hello Michael, Thanks for pointing it out. Actually, it was a nice headsup for us. We were missing the fact that 2.2.x is LTS so I'm marking this as a TODO for this month in 20.10 cycle. Will keep this bug updated about it! ** Tags removed: server-triage-discuss ** Changed in: haproxy (Ubuntu) Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco) -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to haproxy in Ubuntu. https://bugs.launchpad.net/bugs/1890314 Title: RFE HAProxy 2.2 for groovy Status in haproxy package in Ubuntu: Triaged Bug description: Is there any chance of getting HAProxy 2.2.x (LTS) into the 20.10 groovy release? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1890314/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1890314] Re: RFE HAProxy 2.2 for groovy
** Changed in: haproxy (Ubuntu) Status: New => Triaged ** Changed in: haproxy (Ubuntu) Importance: Undecided => Wishlist ** Tags added: server-triage-discuss -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to haproxy in Ubuntu. https://bugs.launchpad.net/bugs/1890314 Title: RFE HAProxy 2.2 for groovy Status in haproxy package in Ubuntu: Triaged Bug description: Is there any chance of getting HAProxy 2.2.x (LTS) into the 20.10 groovy release? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1890314/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1890185] Re: scheduler: support/backport on-fail="demote" recovery policy for promoted resources
This feature is in 2.0.x releases, so SRU for bionic would be out of question: pacemaker | 1.1.18-0ubuntu1 | bionic | source pacemaker | 1.1.18-0ubuntu1.1 | bionic-security | source pacemaker | 1.1.18-0ubuntu1.2 | bionic-updates | source pacemaker | 2.0.1-4ubuntu2| eoan| source pacemaker | 2.0.3-3ubuntu3| focal | source pacemaker | 2.0.4-2ubuntu1| groovy | source and Eoan is not LTS so the effort is not worth. That would make the need for: To backport (1) 874f75e0f - Feature: scheduler: new on-fail="demote" recovery policy for promoted resources 2f1e2df1f - Feature: xml: add on-fail="demote" option to resources schema and all related patches to Focal. (2) To make sure Groovy catches up with the feature or to backport similar patches to Groovy. ** Changed in: pacemaker (Ubuntu Bionic) Status: New => Won't Fix ** Changed in: pacemaker (Ubuntu Eoan) Status: New => Won't Fix ** Changed in: pacemaker (Ubuntu Focal) Status: New => Triaged ** Changed in: pacemaker (Ubuntu Focal) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1890185 Title: scheduler: support/backport on-fail="demote" recovery policy for promoted resources Status in pacemaker package in Ubuntu: Triaged Status in pacemaker source package in Bionic: Won't Fix Status in pacemaker source package in Eoan: Won't Fix Status in pacemaker source package in Focal: Triaged Bug description: There is a request for the feature: Feature: scheduler: new on-fail="demote" recovery policy for promoted… to be backported to Ubuntu LTS versions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1890185/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1890185] Re: scheduler: support/backport on-fail="demote" recovery policy for promoted resources
** Also affects: pacemaker (Ubuntu Eoan) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1890185 Title: scheduler: support/backport on-fail="demote" recovery policy for promoted resources Status in pacemaker package in Ubuntu: Triaged Status in pacemaker source package in Bionic: New Status in pacemaker source package in Eoan: New Status in pacemaker source package in Focal: New Bug description: There is a request for the feature: Feature: scheduler: new on-fail="demote" recovery policy for promoted… to be backported to Ubuntu LTS versions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1890185/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1890185] [NEW] scheduler: support/backport on-fail="demote" recovery policy for promoted resources
Public bug reported: There is a request for the feature: Feature: scheduler: new on-fail="demote" recovery policy for promoted… to be backported to Ubuntu LTS versions. ** Affects: pacemaker (Ubuntu) Importance: Medium Status: Triaged ** Affects: pacemaker (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: pacemaker (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: pacemaker (Ubuntu) Status: New => Triaged ** Changed in: pacemaker (Ubuntu) Importance: Undecided => Medium ** Also affects: pacemaker (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: pacemaker (Ubuntu Bionic) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1890185 Title: scheduler: support/backport on-fail="demote" recovery policy for promoted resources Status in pacemaker package in Ubuntu: Triaged Status in pacemaker source package in Bionic: New Status in pacemaker source package in Focal: New Bug description: There is a request for the feature: Feature: scheduler: new on-fail="demote" recovery policy for promoted… to be backported to Ubuntu LTS versions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1890185/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1886546] Re: pacemaker - 2.0.3-3ubuntu3 needs update (2.0.4-2)
** Description changed: - pacemaker - 2.0.3-3ubuntu3 needs update (2.0.4-2) + BUG: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1886546 + PPA: https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1886546 + MERGE: ** Description changed: BUG: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1886546 PPA: https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1886546 - MERGE: + MERGE: https://tinyurl.com/y83wtxny -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1886546 Title: pacemaker - 2.0.3-3ubuntu3 needs update (2.0.4-2) Status in pacemaker package in Ubuntu: In Progress Bug description: BUG: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1886546 PPA: https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1886546 MERGE: https://tinyurl.com/y83wtxny To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1886546/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1886546] [NEW] pacemaker - 2.0.3-3ubuntu3 needs update (2.0.4-2)
Public bug reported: pacemaker - 2.0.3-3ubuntu3 needs update (2.0.4-2) ** Affects: pacemaker (Ubuntu) Importance: Medium Status: In Progress ** Changed in: pacemaker (Ubuntu) Status: New => In Progress ** Changed in: pacemaker (Ubuntu) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1886546 Title: pacemaker - 2.0.3-3ubuntu3 needs update (2.0.4-2) Status in pacemaker package in Ubuntu: In Progress Bug description: pacemaker - 2.0.3-3ubuntu3 needs update (2.0.4-2) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1886546/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1881762] Re: resource timeout not respecting units
** Changed in: pacemaker (Ubuntu) Status: New => Triaged ** Changed in: pacemaker (Ubuntu) Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco) -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1881762 Title: resource timeout not respecting units Status in pacemaker package in Ubuntu: Triaged Bug description: While working on pacemaker, i discovered a issue with timeouts haproxy_stop_0 on primary 'OCF_TIMEOUT' (198): call=583, status='Timed Out', exitreason='', last-rc-change='1970-01-04 17:21:18 -05:00', queued=44ms, exec=176272ms this lead me down the path of finding that setting a timeout unit value was not doing anything primitive haproxy systemd:haproxy \ op monitor interval=2s \ op start interval=0s timeout=500s \ op stop interval=0s timeout=500s \ meta migration-threshold=2 primitive haproxy systemd:haproxy \ op monitor interval=2s \ op start interval=0s timeout=500 \ op stop interval=0s timeout=500 \ meta migration-threshold=2 the two above configs result in the same behaviour, pacemaker/crm seems to be ignoring the "s" I file a bug with pacemaker itself https://bugs.clusterlabs.org/show_bug.cgi?id=5429 but this lead to the following responsed, copied from the ticket: <https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1881762/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1412438] Re: OCF:pacemaker:o2cb broken in 14.04
*** This bug is a duplicate of bug 1869643 ***
https://bugs.launchpad.net/bugs/1869643
Thank you for taking the time to report this bug. In an effort to keep an
up-to-date and valid list of bugs to work on, I have reviewed this report to
verify it still requires effort and occurs on an Ubuntu release in standard
support.
This is and old behavior that might still be present in current
resource-agents package agents and is being drive at:
https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug/1869643
I'm marking this as duplicate so I can keep track of same issues for the
recent Ubuntu versions in an easier way.
** Also affects: ocfs2-tools (Ubuntu Trusty)
Importance: Undecided
Status: New
** Also affects: ocfs2-tools (Ubuntu Precise)
Importance: Undecided
Status: New
** This bug has been marked a duplicate of bug 1869643
{fence,resource}-agents: PATH for all binaries called by all agents should
be resolvable
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed to ocfs2-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1412438
Title:
OCF:pacemaker:o2cb broken in 14.04
Status in ocfs2-tools package in Ubuntu:
Confirmed
Status in ocfs2-tools source package in Precise:
New
Status in ocfs2-tools source package in Trusty:
New
Bug description:
The pacemaker resource agent ocf:pacemaker:o2cb requires
/usr/sbin/ocfs2_controld.pcmk
in order to execute correctly. This binary used to be in ocsf2-tools-
pacemaker in earlier releases (e.g. 12.04). However, this is omitted
from 14.04. As a result, resource agent is broken and pacemaker cannot
be used to manage ocfs2 file systems
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ocfs2-tools/+bug/1412438/+subscriptions
___
Mailing list: https://launchpad.net/~ubuntu-ha
Post to : ubuntu-ha@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-ha
More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1584629] Re: Failed to start LSB: Load O2CB cluster services at system boot.
Thank you for taking the time to report this bug. In an effort to keep an up-to-date and valid list of bugs to work on, I have reviewed this report to verify it still requires effort and occurs on an Ubuntu release in standard support, and it does not. It is unfortunate that we were unable to resolve this defect, however there appears to be no further action possible at this time. I am therefore moving the bug to 'Fix Released' to current development release as the issue does not apply to it any longer. If you disagree or have new information, we would be grateful if you could please open a new bug mentioning new affected versions with a possible reproducer in the bug description. ** Changed in: ocfs2-tools (Ubuntu Trusty) Status: New => Triaged ** No longer affects: ocfs2-tools (Ubuntu Xenial) ** No longer affects: ocfs2-tools (Ubuntu Yakkety) ** Changed in: ocfs2-tools (Ubuntu) Status: Triaged => Fix Released ** Changed in: ocfs2-tools (Ubuntu Trusty) Importance: Undecided => Low -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to ocfs2-tools in Ubuntu. https://bugs.launchpad.net/bugs/1584629 Title: Failed to start LSB: Load O2CB cluster services at system boot. Status in ocfs2-tools package in Ubuntu: Fix Released Status in ocfs2-tools source package in Trusty: Triaged Bug description: Ubuntu 16.04. Sometimes (not every boot) o2cb failed to start: systemctl status o2cb ● o2cb.service - LSB: Load O2CB cluster services at system boot. Loaded: loaded (/etc/init.d/o2cb; bad; vendor preset: enabled) Active: failed (Result: exit-code) since Пн 2016-05-23 11:46:43 SAMT; 2min 12s ago Docs: man:systemd-sysv-generator(8) Process: 1526 ExecStart=/etc/init.d/o2cb start (code=exited, status=1/FAILURE) май 23 11:46:43 inetgw1 systemd[1]: Starting LSB: Load O2CB cluster services at system boot май 23 11:46:43 inetgw1 o2cb[1526]: Loading filesystem "configfs": OK май 23 11:46:43 inetgw1 o2cb[1526]: Mounting configfs filesystem at /sys/kernel/config: mount: configfs is already май 23 11:46:43 inetgw1 o2cb[1526]:configfs is already mounted on /sys/kernel/config май 23 11:46:43 inetgw1 o2cb[1526]: Unable to mount configfs filesystem май 23 11:46:43 inetgw1 o2cb[1526]: Failed май 23 11:46:43 inetgw1 systemd[1]: o2cb.service: Control process exited, code=exited status=1 май 23 11:46:43 inetgw1 systemd[1]: Failed to start LSB: Load O2CB cluster services at system boot.. май 23 11:46:43 inetgw1 systemd[1]: o2cb.service: Unit entered failed state. май 23 11:46:43 inetgw1 systemd[1]: o2cb.service: Failed with result 'exit-code'. next try is successful: systemctl status o2cb ● o2cb.service - LSB: Load O2CB cluster services at system boot. Loaded: loaded (/etc/init.d/o2cb; bad; vendor preset: enabled) Active: active (exited) since Пн 2016-05-23 11:49:07 SAMT; 1s ago Docs: man:systemd-sysv-generator(8) Process: 2101 ExecStart=/etc/init.d/o2cb start (code=exited, status=0/SUCCESS) май 23 11:49:07 inetgw1 systemd[1]: Starting LSB: Load O2CB cluster services at system boot май 23 11:49:07 inetgw1 o2cb[2101]: Loading stack plugin "o2cb": OK май 23 11:49:07 inetgw1 o2cb[2101]: Loading filesystem "ocfs2_dlmfs": OK май 23 11:49:07 inetgw1 o2cb[2101]: Mounting ocfs2_dlmfs filesystem at /dlm: OK май 23 11:49:07 inetgw1 o2cb[2101]: Setting cluster stack "o2cb": OK май 23 11:49:07 inetgw1 o2cb[2101]: Starting O2CB cluster inetgw: OK май 23 11:49:07 inetgw1 systemd[1]: Started LSB: Load O2CB cluster services at system boot.. I guess this is startup dependency problem. Thank you! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ocfs2-tools/+bug/1584629/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1449046] Re: needing non existed file
*** This bug is a duplicate of bug 1869643 ***
https://bugs.launchpad.net/bugs/1869643
** This bug is no longer a duplicate of bug 1412438
OCF:pacemaker:o2cb broken in 14.04
** This bug has been marked a duplicate of bug 1869643
{fence,resource}-agents: PATH for all binaries called by all agents should
be resolvable
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed to ocfs2-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1449046
Title:
needing non existed file
Status in ocfs2-tools package in Ubuntu:
Confirmed
Bug description:
$ lsb_release -rd
Description: Ubuntu 14.04.2 LTS
Release: 14.04
$ sudo apt-cache policy ocfs2-tools
[sudo] password for termant:
ocfs2-tools:
Installed: 1.6.4-3ubuntu1
Candidate: 1.6.4-3ubuntu1
Version table:
*** 1.6.4-3ubuntu1 0
500 http://fi.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
100 /var/lib/dpkg/status
I have installed the following packages:
apt-get install drbd8-utils corosync pacemaker dlm clvm ocfs2-tools
Then in my pacemaker configuration (using crm) I have defined
primitive p-drbd ocf:linbit:drbd \
params drbd_resource="md2" \
op monitor interval="50" role="Master" timeout="30" \
op monitor interval="60" role="Slave" timeout="30" \
op start interval="0" timeout="240" \
op stop interval="0" timeout="100"
ms ms-drbd p-drbd \
meta master-max="2" clone-max="2" notify="true" interleave="true"
primitive p-dlm ocf:pacemaker:controld \
op monitor interval="120" timeout="30" \
op start interval="0" timeout="90" \
op stop interval="0" timeout="100"
primitive p-clvm ocf:lvm2:clvmd \
params daemon_timeout="30" \
op monitor interval="60" timeout="30" \
op start interval="0" timeout="90" \
op stop interval="0" timeout="100"
primitive p-o2cb ocf:pacemaker:o2cb \
op monitor interval="120" timeout="30" \
op start interval="0" timeout="90" \
op stop interval="0" timeout="100"
group g-lock p-dlm p-clvm p-o2cb
clone c-lock g-lock \
meta globally-unique="false" interleave="true"
colocation col-drbd-lock inf: c-lock ms-drbd:Master
order ord-drbd-lock inf: ms-drbd:promote c-lock
When I started my cluster with two nodes, output of the crm_mon tool
was following:
Last updated: Mon Apr 27 16:25:46 2015
Last change: Mon Apr 27 16:14:07 2015 via cibadmin on node1
Stack: corosync
Current DC: node2 (2) - partition with quorum
Version: 1.1.10-42f2063
2 Nodes configured
10 Resources configured
Online: [ node1 node2 ]
p-ipmi-stonith-node1 (stonith:fence_ipmilan):Started node2
p-ipmi-stonith-node2 (stonith:fence_ipmilan):Started node1
Master/Slave Set: ms-drbd [p-drbd]
Masters: [ node1 node2 ]
Failed actions:
p-o2cb_monitor_0 (node=node1, call=275, rc=5, status=complete,
last-rc-change
=Mon Apr 27 16:25:45 2015
, queued=18ms, exec=0ms
): not installed
p-o2cb_monitor_0 (node=node2, call=66, rc=5, status=complete,
last-rc-chang
e=Mon Apr 27 16:25:45 2015
, queued=21ms, exec=0ms
): not installed
What I expected was:
Online: [ node1 node2 ]
Master/Slave Set: ms-drbd [p-drbd]
Masters: [ node2 node1 ]
Clone Set: c-lock [g-lock]
Started: [ node1 node2 ]
/var/log/syslog indicates that file /usr/sbin/ocfs2_controld.pcmk is
missing (ERROR: Setup problem: couldn't find command:
/usr/sbin/ocfs2_controld.pcmk). Then I searched a package which
contains this file but I couldn't find a match for Ubuntu 14.04. But,
there had been a file ocfs2-tools-pacemaker which includes this file,
which is now missing.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ocfs2-tools/+bug/1449046/+subscriptions
___
Mailing list: https://launchpad.net/~ubuntu-ha
Post to : ubuntu-ha@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-ha
More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1879106] Re: Sync ocfs2-tools 1.8.6-3 (main) from Debian unstable (main)
This bug was fixed in the package ocfs2-tools - 1.8.6-5 Sponsored for Logan Rosen (logan) --- ocfs2-tools (1.8.6-5) unstable; urgency=medium * debian/control: limit build to linux architectures -- Valentin Vidic Thu, 21 May 2020 14:10:56 +0200 ocfs2-tools (1.8.6-4) unstable; urgency=medium * debian/patches: fix o2image segfault on s390x * debian/lintian-overrides: ignore manpage warning * debian/tests: update test output * debian/rules: move startup scripts to /usr/libexec -- Valentin Vidic Thu, 21 May 2020 13:35:08 +0200 ocfs2-tools (1.8.6-3) unstable; urgency=medium * debian/salsa-ci.yml: enable CI * debian/control: specify only supported architectures (LP: #1745155) * debian/salsa-ci.yml: disable blhc warnings * debian/control: update Standards-Version to 4.5.0 * debian/control: use debhelper v13 * debian/control: update Maintainer mailing list address * debian/NEWS: fix file name -- Valentin Vidic Wed, 13 May 2020 21:31:59 +0200 ** Changed in: ocfs2-tools (Ubuntu) Status: Triaged => Fix Released -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to ocfs2-tools in Ubuntu. https://bugs.launchpad.net/bugs/1879106 Title: Sync ocfs2-tools 1.8.6-3 (main) from Debian unstable (main) Status in ocfs2-tools package in Ubuntu: Fix Released Bug description: Please sync ocfs2-tools 1.8.6-3 (main) from Debian unstable (main) Explanation of the Ubuntu delta and why it can be dropped: * debian/control: specify only supported architectures (LP: #1745155) The same change was made in Debian. Changelog entries since current groovy version 1.8.6-2ubuntu1: ocfs2-tools (1.8.6-3) unstable; urgency=medium * debian/salsa-ci.yml: enable CI * debian/control: specify only supported architectures (LP: #1745155) * debian/salsa-ci.yml: disable blhc warnings * debian/control: update Standards-Version to 4.5.0 * debian/control: use debhelper v13 * debian/control: update Maintainer mailing list address * debian/NEWS: fix file name -- Valentin Vidic Wed, 13 May 2020 21:31:59 +0200 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ocfs2-tools/+bug/1879106/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 246613] Re: ocfs2 startup link prior to open-iscsi
Thank you for taking the time to report this bug. In an effort to keep an up-to-date and valid list of bugs to work on, I have reviewed this report to verify it still requires effort and occurs on an Ubuntu release in standard support, and it does not. It is unfortunate that we were unable to resolve this defect, however there appears to be no further action possible at this time. I am therefore moving the bug to 'Fix Released' to current development release as the issue does not apply to it any longer. If you disagree or have new information, we would be grateful if you could please open a new bug mentioning new affected versions with a possible reproducer in the bug description. ** Changed in: ocfs2-tools (Ubuntu) Status: Confirmed => Fix Released ** Also affects: ocfs2-tools (Ubuntu Precise) Importance: Undecided Status: New ** Changed in: ocfs2-tools (Ubuntu Precise) Status: New => Won't Fix -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to ocfs2-tools in Ubuntu. https://bugs.launchpad.net/bugs/246613 Title: ocfs2 startup link prior to open-iscsi Status in ocfs2-tools package in Ubuntu: Fix Released Status in ocfs2-tools source package in Precise: Won't Fix Bug description: Binary package hint: ocfs2-tools The ocfs2-tools package creates a startup link at /etc/rcS.d/S65ocfs2. However, the ocfs2 filesystem is (as I understand it) intended for use as a network shared file system. A common way to accomplish this is through the use of iSCSI. The startup link for open-iscsi is created at /etc/rc2.d/S20open-iscsi which means that when ocfs2 starts the iSCSI layer is not yet in place and thus the volume(s) are not mounted. Moving the ocfs2 startup link to /etc/rc2.d corrects the issue. I'm not sure if the link for ocfs2 or open-iscsi should be the one to move. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ocfs2-tools/+bug/246613/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1018671] Re: mismatch between ocfs2-tools version and kernel
Thank you for taking the time to report this bug. In an effort to keep an up-to-date and valid list of bugs to work on, I have reviewed this report to verify it still requires effort and occurs on an Ubuntu release in standard support, and it does not. It is unfortunate that we were unable to resolve this defect, however there appears to be no further action possible at this time. I am therefore moving the bug to 'Fix Released' to current development release as the issue does not apply to it any longer. If you disagree or have new information, we would be grateful if you could please open a new bug mentioning new affected versions with a possible reproducer in the bug description. ** Also affects: ocfs2-tools (Ubuntu Precise) Importance: Undecided Status: New ** Changed in: ocfs2-tools (Ubuntu Precise) Status: New => Won't Fix ** Changed in: ocfs2-tools (Ubuntu) Status: Confirmed => Fix Released ** Changed in: ocfs2-tools (Ubuntu) Importance: High => Undecided -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to ocfs2-tools in Ubuntu. https://bugs.launchpad.net/bugs/1018671 Title: mismatch between ocfs2-tools version and kernel Status in ocfs2-tools package in Ubuntu: Fix Released Status in ocfs2-tools source package in Precise: Won't Fix Bug description: In at least 11.10 (likely 12.04 as well, however...), the ocfs2-tools is behind what the 3.0 kernel is creating on disk. This can be seen trivially by attempting to examine the locks on an ocfs2 filesystem: ===# debugfs.ocfs2 -n -R "fs_locks" /dev/dm-1 Debug string proto 3 found, but 2 is the highest I understand. The 1.8 tree in the ocfs2-tools git repo includes support for proto 3. That set of tools should probably be distributed with 11.10 and up, so that the tools match what the kernel is providing. Not having the tools match up to the kernel makes things very difficult, like trying to debug locking issues. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ocfs2-tools/+bug/1018671/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 474215] Re: mountall-net tries to mount ocfs2 before o2cb is started
Thank you for taking the time to report this bug. In an effort to keep an up-to-date and valid list of bugs to work on, I have reviewed this report to verify it still requires effort and occurs on an Ubuntu release in standard support, and it does not. It is unfortunate that we were unable to resolve this defect, however there appears to be no further action possible at this time. I am therefore moving the bug to 'Fix Released' to current development release as the issue does not apply to it any longer. If you disagree or have new information, we would be grateful if you could please open a new bug mentioning new affected versions with a possible reproducer in the bug description. ** Also affects: ocfs2-tools (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: ocfs2-tools (Ubuntu Precise) Importance: Undecided Status: New ** Changed in: ocfs2-tools (Ubuntu Trusty) Status: New => Won't Fix ** Changed in: ocfs2-tools (Ubuntu Precise) Status: New => Won't Fix ** Changed in: ocfs2-tools (Ubuntu Trusty) Status: Won't Fix => Triaged ** Changed in: ocfs2-tools (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to ocfs2-tools in Ubuntu. https://bugs.launchpad.net/bugs/474215 Title: mountall-net tries to mount ocfs2 before o2cb is started Status in ocfs2-tools package in Ubuntu: Fix Released Status in ocfs2-tools source package in Precise: Won't Fix Status in ocfs2-tools source package in Trusty: Triaged Bug description: Binary package hint: ocfs2-tools Upstart tries to mount an ocfs2 filesystem defined in fstab before /etc/init.d/o2cb has been run, the mount therefore fails. As a workaround I run '/etc/init.d/o2cb start' in mountall-net.conf. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ocfs2-tools/+bug/474215/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1879106] Re: Sync ocfs2-tools 1.8.6-3 (main) from Debian unstable (main)
Hello Logan, I haven't started yet the work of merging and syncing HA packages for 20.10, but will do very soon. Added this to my queue! Thank you! ** Changed in: ocfs2-tools (Ubuntu) Status: New => Triaged ** Changed in: ocfs2-tools (Ubuntu) Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco) -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to ocfs2-tools in Ubuntu. https://bugs.launchpad.net/bugs/1879106 Title: Sync ocfs2-tools 1.8.6-3 (main) from Debian unstable (main) Status in ocfs2-tools package in Ubuntu: Triaged Bug description: Please sync ocfs2-tools 1.8.6-3 (main) from Debian unstable (main) Explanation of the Ubuntu delta and why it can be dropped: * debian/control: specify only supported architectures (LP: #1745155) The same change was made in Debian. Changelog entries since current groovy version 1.8.6-2ubuntu1: ocfs2-tools (1.8.6-3) unstable; urgency=medium * debian/salsa-ci.yml: enable CI * debian/control: specify only supported architectures (LP: #1745155) * debian/salsa-ci.yml: disable blhc warnings * debian/control: update Standards-Version to 4.5.0 * debian/control: use debhelper v13 * debian/control: update Maintainer mailing list address * debian/NEWS: fix file name -- Valentin Vidic Wed, 13 May 2020 21:31:59 +0200 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ocfs2-tools/+bug/1879106/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
TL;DR TODO SUMMARY:
- netplan change to support KeepConfiguration= for systemd-networkd backend
(Groovy)
- backport this change: netplan for Ubuntu Focal (SRU)
- backport this change: netplan for Ubuntu Eoan (SRU, WontFix due to EOL ?)
- backport this change: netplan for Ubuntu Bionic (SRU)
- backport this change: netplan for Ubuntu Xenial (SRU, WontFix ?)
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed to keepalived in Ubuntu.
https://bugs.launchpad.net/bugs/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Won't Fix
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in keepalived source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Confirmed
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
Confirmed
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in keepalived source package in Focal:
Confirmed
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
- ALL related HA software has a small problem if interfaces are being
managed by systemd-networkd: nic restarts/reconfigs are always going
to wipe all interfaces aliases when HA software is not expecting it to
(no coordination between them.
- keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
smarter in this case because it has a service monitor that will
restart the virtual IP resource, in affected node & nic, before
considering a real failure, but other HA service might consider a real
failure when it is not.
[test case]
- comment #14 is a full test case: to have 3 node pacemaker, in that
example, and cause a networkd service restart: it will trigger a
failure for the virtual IP resource monitor.
- other example is given in the original description for keepalived.
both suffer from the same issue (and other HA softwares as well).
[regression potential]
- this backports KeepConfiguration parameter, which adds some
significant complexity to networkd's configuration and behavior, which
could lead to regressions in correctly configuring the network at
networkd start, or incorrectly maintaining configuration at networkd
restart, or losing network state at networkd stop.
- Any regressions are most likely to occur during networkd start,
restart, or stop, and most likely to involve missing or incorrect ip
address(es).
- the change is based in upstream patches adding the exact feature we
needed to fix this issue & it will be integrated with a netplan change
to add the needed stanza to systemd nic configuration file
(KeepConfiguration=)
[other info]
original description:
---
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't
[Ubuntu-ha] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
@napsty: the "workaround" (from your blog) is actually to use:
- ifupdown/bridge-utils/vlan/resolvconf for network setup OR
- use systemd-networkd DIRECTLY with the KeepConfiguration= option in .network
file
Just highlighting it here.
@ddstreet, you said you would try to come up with the netplan change for
KeepConfiguration. Did you have time to check on this ? (just checking).
Cheers o/
** Changed in: keepalived (Ubuntu)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Changed in: keepalived (Ubuntu Xenial)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Changed in: keepalived (Ubuntu Bionic)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Changed in: keepalived (Ubuntu Disco)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Changed in: keepalived (Ubuntu Eoan)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Changed in: systemd (Ubuntu)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Changed in: systemd (Ubuntu Xenial)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Changed in: systemd (Ubuntu Bionic)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Changed in: systemd (Ubuntu Disco)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Changed in: systemd (Ubuntu Eoan)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Changed in: netplan
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** No longer affects: keepalived (Ubuntu Eoan)
** No longer affects: keepalived (Ubuntu Disco)
** Also affects: heartbeat (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: keepalived (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: systemd (Ubuntu Focal)
Importance: Undecided
Status: New
** Changed in: systemd (Ubuntu Focal)
Status: New => Fix Released
** Changed in: keepalived (Ubuntu Focal)
Status: New => Confirmed
** No longer affects: heartbeat (Ubuntu Focal)
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed to keepalived in Ubuntu.
https://bugs.launchpad.net/bugs/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Won't Fix
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in keepalived source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Confirmed
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
Confirmed
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in keepalived source package in Focal:
Confirmed
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
- ALL related HA software has a small problem if interfaces are being
managed by systemd-networkd: nic restarts/reconfigs are always going
to wipe all interfaces aliases when HA software is not expecting it to
(no coordination between them.
- keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
smarter in this case because it has a service monitor that will
restart the virtual IP resource, in affected node & nic, before
considering a real failure, but other HA service might consider a real
failure when it is not.
[test case]
- comment #14 is a full test case: to have 3 node pacemaker, in that
example, and cause a networkd service restart: it will trigger a
failure for the virtual IP resource monitor.
- other example is given in the original description for keepalived.
both suffer from the same issue (and other HA softwares as well).
[regression potential]
- this backports KeepConfiguration parameter, which adds some
significant complexity to networkd's configuration and behavior, which
could lead to regressions in correctly configuring the network at
networkd start, or incorrectly maintaining configuration at networkd
restart, or losing network state at networkd stop.
- Any regressions are most likely to occur during networkd start,
restart, or stop, and most likely to involve missing or incorrect ip
address(es).
- the change is based in upstream patches adding the exact feature we
needed to fix this issue & it will be integrated with a netplan change
to add the needed stanza to systemd nic configuration file
(KeepConfiguration=)
[other info]
original description:
---
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
[Ubuntu-ha] [Bug 1874719] Re: Focal deploy creates a 'node1' node
** Changed in: pacemaker (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1874719 Title: Focal deploy creates a 'node1' node Status in OpenStack hacluster charm: New Status in pacemaker package in Ubuntu: Invalid Bug description: Testing of masakari on focal zaza tests failed because the test checks that all pacemaker nodes are online. This check failed due the appearance of a new node called 'node1' which was marked as offline. I don't know where that node came from or what is supposed to represent but it seems like an unwanted change in behaviour. To manage notifications about this bug go to: https://bugs.launchpad.net/charm-hacluster/+bug/1874719/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1874719] Re: Focal deploy creates a 'node1' node
Here you will find the autopkgtests for pacemaker: http://autopkgtest.ubuntu.com/packages/p/pacemaker/focal/amd64 the installation ends with a corosync node online: Cluster Summary: * Stack: corosync * Current DC: node1 (version 2.0.3-4b1f869f0f) - partition with quorum * Last updated: Fri Apr 17 22:55:34 2020 * Last change: Fri Apr 17 22:55:22 2020 by hacluster via crmd on node1 * 1 node configured * 0 resource instances configured Node List: * Online: [ node1 ] Active Resources: * No active resources pacemakerPASS pacemakerPASS So, for some reason, this localhost corosync installation made the service to be unavailable in your cause. I wonder if you have more logs so we can check what happened for it not to be online. -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1874719 Title: Focal deploy creates a 'node1' node Status in OpenStack hacluster charm: New Status in pacemaker package in Ubuntu: New Bug description: Testing of masakari on focal zaza tests failed because the test checks that all pacemaker nodes are online. This check failed due the appearance of a new node called 'node1' which was marked as offline. I don't know where that node came from or what is supposed to represent but it seems like an unwanted change in behaviour. To manage notifications about this bug go to: https://bugs.launchpad.net/charm-hacluster/+bug/1874719/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1874719] Re: Focal deploy creates a 'node1' node
** Changed in: pacemaker (Ubuntu) Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco) -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1874719 Title: Focal deploy creates a 'node1' node Status in OpenStack hacluster charm: New Status in pacemaker package in Ubuntu: New Bug description: Testing of masakari on focal zaza tests failed because the test checks that all pacemaker nodes are online. This check failed due the appearance of a new node called 'node1' which was marked as offline. I don't know where that node came from or what is supposed to represent but it seems like an unwanted change in behaviour. To manage notifications about this bug go to: https://bugs.launchpad.net/charm-hacluster/+bug/1874719/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1866119] Re: [bionic] fence_scsi not working properly with Pacemaker 1.1.18-2ubuntu1.1
Okay, I had verified this from the day in it landed in -proposed. It is working as expected (https://discourse.ubuntu.com/t/ubuntu-high- availability-corosync-pacemaker-shared-disk-environments/). I'm marking this as verification-done as it has stayed in -proposed for sometime now and no bad feedback was given from those who were asked to test it. ** Tags removed: block-proposed-bionic verification-needed verification-needed-bionic ** Tags added: verification-done verification-done-bionic -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1866119 Title: [bionic] fence_scsi not working properly with Pacemaker 1.1.18-2ubuntu1.1 Status in pacemaker package in Ubuntu: Fix Released Status in pacemaker source package in Bionic: Fix Committed Bug description: OBS: This bug was originally into LP: #1865523 but it was split. SRU: pacemaker [Impact] * fence_scsi is not currently working in a share disk environment * all clusters relying in fence_scsi and/or fence_scsi + watchdog won't be able to start the fencing agents OR, in worst case scenarios, the fence_scsi agent might start but won't make scsi reservations in the shared scsi disk. * this bug is taking care of pacemaker 1.1.18 issues with fence_scsi, since the later was fixed at LP: #1865523. [Test Case] * having a 3-node setup, nodes called "clubionic01, clubionic02, clubionic03", with a shared scsi disk (fully supporting persistent reservations) /dev/sda, with corosync and pacemaker operational and running, one might try: rafaeldtinoco@clubionic01:~$ crm configure crm(live)configure# property stonith-enabled=on crm(live)configure# property stonith-action=off crm(live)configure# property no-quorum-policy=stop crm(live)configure# property have-watchdog=true crm(live)configure# commit crm(live)configure# end crm(live)# end rafaeldtinoco@clubionic01:~$ crm configure primitive fence_clubionic \ stonith:fence_scsi params \ pcmk_host_list="clubionic01 clubionic02 clubionic03" \ devices="/dev/sda" \ meta provides=unfencing And see the following errors: Failed Actions: * fence_clubionic_start_0 on clubionic02 'unknown error' (1): call=6, status=Error, exitreason='', last-rc-change='Wed Mar 4 19:53:12 2020', queued=0ms, exec=1105ms * fence_clubionic_start_0 on clubionic03 'unknown error' (1): call=6, status=Error, exitreason='', last-rc-change='Wed Mar 4 19:53:13 2020', queued=0ms, exec=1109ms * fence_clubionic_start_0 on clubionic01 'unknown error' (1): call=6, status=Error, exitreason='', last-rc-change='Wed Mar 4 19:53:11 2020', queued=0ms, exec=1108ms and corosync.log will show: warning: unpack_rsc_op_failure: Processing failed op start for fence_clubionic on clubionic01: unknown error (1) [Regression Potential] * LP: #1865523 shows fence_scsi fully operational after SRU for that bug is done. * LP: #1865523 used pacemaker 1.1.19 (vanilla) in order to fix fence_scsi. * There are changes to: cluster resource manager daemon, local resource manager daemon and police engine. From all the changes, the police engine fix is the biggest, but still not big for a SRU. This could cause police engine, thus cluster decisions, to mal function. * All patches are based in upstream fixes made right after Pacemaker-1.1.18, used by Ubuntu Bionic and were tested with fence_scsi to make sure it fixed the issues. [Other Info] * Original Description: Trying to setup a cluster with an iscsi shared disk, using fence_scsi as the fencing mechanism, I realized that fence_scsi is not working in Ubuntu Bionic. I first thought it was related to Azure environment (LP: #1864419), where I was trying this environment, but then, trying locally, I figured out that somehow pacemaker 1.1.18 is not fencing the shared scsi disk properly. Note: I was able to "backport" vanilla 1.1.19 from upstream and fence_scsi worked. I have then tried 1.1.18 without all quilt patches and it didnt work as well. I think that bisecting 1.1.18 <-> 1.1.19 might tell us which commit has fixed the behaviour needed by the fence_scsi agent. (k)rafaeldtinoco@clubionic01:~$ crm conf show node 1: clubionic01.private node 2: clubionic02.private node 3: clubionic03.private primitive fence_clubionic stonith:fence_scsi \ params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ meta provides=unfencing property cib-bootstrap-options: \ have-watchdog=false \ dc-version=1.1.18-2b07d5c5a9 \ cluster-infrastructure=corosync \ cluster-name=clubionic \ stonith-enabled=on \ stonith-action=off \ no-quorum-policy=stop \ symmetric-cluster=true
[Ubuntu-ha] [Bug 1871353] Re: after split brain detection heartbeart service stops unexpectedly
** Changed in: heartbeat (Ubuntu) Status: New => Triaged ** Changed in: heartbeat (Ubuntu) Importance: Undecided => Medium ** Also affects: heartbeat (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: heartbeat (Ubuntu Xenial) Status: New => Triaged ** Changed in: heartbeat (Ubuntu Xenial) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to heartbeat in Ubuntu. https://bugs.launchpad.net/bugs/1871353 Title: after split brain detection heartbeart service stops unexpectedly Status in heartbeat package in Ubuntu: Triaged Status in heartbeat source package in Xenial: Triaged Bug description: Ubuntu Release -- Description: Ubuntu 16.04.6 LTS Release: 16.04 heartbeat Package - heartbeat: Installed: 1:3.0.6-2 Candidate: 1:3.0.6-2 Version table: *** 1:3.0.6-2 500 500 http://mirror.hetzner.de/ubuntu/packages xenial/main amd64 Packages 100 /var/lib/dpkg/status Scenario Description When heartbeat detects a split brain scenario a restart is triggered by the heartbeat service itself. Expectation --- The heartbeat service should be running after a split brain scenario was detected. Obervation -- The heartbeat service was no longer running after the split brain scenario. Further Investigation - systemd detects the restart and executes the ExecStop action. This behaviour is documented at https://www.freedesktop.org/software/systemd/man/systemd.service.html#ExecStop= This problem most likely arises because of the automatically generated systemctl service file (converted from the init.d script by systemd- sysv-generator). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/heartbeat/+bug/1871353/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1828228] Re: corosync fails to start in unprivileged containers - autopkgtest failure
** Changed in: pcs (Ubuntu) Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned) ** Changed in: pacemaker (Ubuntu) Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned) ** Changed in: corosync (Ubuntu) Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned) -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to corosync in Ubuntu. https://bugs.launchpad.net/bugs/1828228 Title: corosync fails to start in unprivileged containers - autopkgtest failure Status in Auto Package Testing: Invalid Status in corosync package in Ubuntu: Fix Released Status in pacemaker package in Ubuntu: Fix Released Status in pcs package in Ubuntu: Fix Released Bug description: Currently pacemaker v2 fails to start in armhf containers (and by extension corosync too). I found that it is reproducible locally, and that I had to bump a few limits to get it going. Specifically I did: 1) bump memlock limits 2) bump rmem_max limits = 1) Bump memlock limits = I have no idea, which one of these finally worked, and/or is sufficient. A bit of a whack-a-mole. cat >>/etc/security/limits.conf </etc/systemd/system/snap.lxd.daemon.service.d/override.conf <&1 | grep sockop [pid 447] setsockopt(12, SOL_SOCKET, SO_RCVBUF, [8388608], 4) = 0 [pid 447] getsockopt(12, SOL_SOCKET, SO_RCVBUF, [425984], [4]) = 0 [pid 447] setsockopt(12, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted) Bumped mem_max using: sudo sysctl -w net.core.wmem_max=8388608 sudo sysctl -w net.core.rmem_max=8388608 (Not sure if the desired sized depends on the machine/container I am running on) Can we check the values for above things on our armhf containers and/or bump them? or like can we mark pacemaker v2.0 autopkgtest as ignored on armhf? To manage notifications about this bug go to: https://bugs.launchpad.net/auto-package-testing/+bug/1828228/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1870235] Re: [focal] pacemaker v2.0.3 last upstream fixes
PPA successfully built pacemaker fixes: https://launchpad.net/~ubuntu-server-ha/+archive/ubuntu/staging and the merge request has been +1. ** Description changed: - This bug backport/cherrypick fixes released after 2.0.3 release. - The correct patches are going to be defined within this bug comments. + [Impact] + + * Idea here is latest release stabilization with backports of fixes + released after the current version. + + * Since this is a LTS, it is worth applying "straightforward" fixes + before the final release. + + [Test Case] + + * https://discourse.ubuntu.com/t/ubuntu-high-availability-corosync- + pacemaker-shared-disk-environments/ + + [Regression Potential] + + Areas of potential regression: stonith, pengine, crmservice: + + * stonith: I have regression tests and they look good. + + * pengine: could not identify bad decisions when fencing resources but + haven't explored in detail as there are many possible combinations and + decisions that pengine can take -> changes are very minimal here. + + * crmservice: pacemaker tests don't show regressions, resource agents + start/stop/probe/migrate correctly afaik so the fix looks good. + + [Other Info] + + * This bug backport/cherrypick fixes released after 2.0.3 release. + + * The correct patches are going to be defined within this bug comments. -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1870235 Title: [focal] pacemaker v2.0.3 last upstream fixes Status in pacemaker package in Ubuntu: In Progress Bug description: [Impact] * Idea here is latest release stabilization with backports of fixes released after the current version. * Since this is a LTS, it is worth applying "straightforward" fixes before the final release. [Test Case] * https://discourse.ubuntu.com/t/ubuntu-high-availability-corosync- pacemaker-shared-disk-environments/ [Regression Potential] Areas of potential regression: stonith, pengine, crmservice: * stonith: I have regression tests and they look good. * pengine: could not identify bad decisions when fencing resources but haven't explored in detail as there are many possible combinations and decisions that pengine can take -> changes are very minimal here. * crmservice: pacemaker tests don't show regressions, resource agents start/stop/probe/migrate correctly afaik so the fix looks good. [Other Info] * This bug backport/cherrypick fixes released after 2.0.3 release. * The correct patches are going to be defined within this bug comments. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1870235/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1869751] Re: [focal] pacemaker FTBFS because of deprecated ftime()
Thanks @doko, This was fixed by: # ftime causes deprecation errors now, but the clock_gettime replacement is # disabled by default in 2.0.3. Enable it. CPPFLAGS = -UPCMK_TIME_EMERGENCY_CGT in pacemaker (2.0.3-3ubuntu2) focal; urgency=medium * Forcibly switch from ftime to clock_gettime, since building with ftime now results in deprecation errors -- William Grant Sat, 04 Apr 2020 19:15:34 +1100 I'll rebase my merge request. ** Merge proposal unlinked: https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/pacemaker/+git/pacemaker/+merge/381684 ** Changed in: pacemaker (Ubuntu) Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned) -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1869751 Title: [focal] pacemaker FTBFS because of deprecated ftime() Status in pacemaker package in Ubuntu: Fix Committed Bug description: https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20200327 -focal-focal.html shows that pacemaker started to be FTBFS because of: """ gcc -DHAVE_CONFIG_H -I. -I../../include -DSUPPORT_REMOTE -I../../include -I../../include -I../../libltdl -I../../libltdl -DPCMK_TIME_EMERGENCY_CGT -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/heartbeat -I/usr/include/dbus-1.0 -I/usr/lib/i386-linux-gnu/dbus-1.0/include -fPIE -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -ggdb -fgnu89-inline -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wdeclaration-after-statement -Wendif-labels -Wfloat-equal -Wformat-security -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Wno-long-long -Wno-strict-aliasing -Wpointer-arith -Wwrite-strings -Wunused-but-set-variable -Wformat=2 -Wformat-nonliteral -fstack-protector-strong -Werror -c -o pacemaker_remoted-pacemaker-execd.o `test -f 'pacemaker-execd.c' || echo './'`pacemaker-execd.c execd_commands.c: In function ‘stonith_recurring_op_helper’: execd_commands.c:257:5: error: ‘ftime’ is deprecated [-Werror=deprecated-declarations] 257 | ftime(>t_queue); | ^ In file included from execd_commands.c:23: /usr/include/i386-linux-gnu/sys/timeb.h:39:12: note: declared here 39 | extern int ftime (struct timeb *__timebuf) |^ execd_commands.c: In function ‘schedule_lrmd_cmd’: execd_commands.c:389:5: error: ‘ftime’ is deprecated [-Werror=deprecated-declarations] 389 | ftime(>t_queue); | ^ """ And man page shows: SYNOPSIS #include int ftime(struct timeb *tp); DESCRIPTION NOTE: This function is deprecated, and will be removed in a future version of the GNU C library. Use clock_gettime(2) instead. I'll fix this together with other fixes, opening this bug to track the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1869751/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1870235] Re: [focal] pacemaker v2.0.3 last upstream fixes
** Description changed: - Together with fix for: - - https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1869751 (FTBFS) - - This bug will also backport/cherrypick fixes released after 2.0.3 - release. + This bug backport/cherrypick fixes released after 2.0.3 release. The correct patches are going to be defined within this bug comments. -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1870235 Title: [focal] pacemaker v2.0.3 last upstream fixes Status in pacemaker package in Ubuntu: In Progress Bug description: This bug backport/cherrypick fixes released after 2.0.3 release. The correct patches are going to be defined within this bug comments. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1870235/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1870235] Re: [focal] pacemaker v2.0.3 last upstream fixes
There is an on-going merge request for this bug. -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1870235 Title: [focal] pacemaker v2.0.3 last upstream fixes Status in pacemaker package in Ubuntu: In Progress Bug description: Together with fix for: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1869751 (FTBFS) This bug will also backport/cherrypick fixes released after 2.0.3 release. The correct patches are going to be defined within this bug comments. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1870235/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1869751] Re: [focal] pacemaker FTBFS because of deprecated ftime()
Check: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1870235 for the fix (same merge request). -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1869751 Title: [focal] pacemaker FTBFS because of deprecated ftime() Status in pacemaker package in Ubuntu: Confirmed Bug description: https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20200327 -focal-focal.html shows that pacemaker started to be FTBFS because of: """ gcc -DHAVE_CONFIG_H -I. -I../../include -DSUPPORT_REMOTE -I../../include -I../../include -I../../libltdl -I../../libltdl -DPCMK_TIME_EMERGENCY_CGT -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/heartbeat -I/usr/include/dbus-1.0 -I/usr/lib/i386-linux-gnu/dbus-1.0/include -fPIE -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -ggdb -fgnu89-inline -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wdeclaration-after-statement -Wendif-labels -Wfloat-equal -Wformat-security -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Wno-long-long -Wno-strict-aliasing -Wpointer-arith -Wwrite-strings -Wunused-but-set-variable -Wformat=2 -Wformat-nonliteral -fstack-protector-strong -Werror -c -o pacemaker_remoted-pacemaker-execd.o `test -f 'pacemaker-execd.c' || echo './'`pacemaker-execd.c execd_commands.c: In function ‘stonith_recurring_op_helper’: execd_commands.c:257:5: error: ‘ftime’ is deprecated [-Werror=deprecated-declarations] 257 | ftime(>t_queue); | ^ In file included from execd_commands.c:23: /usr/include/i386-linux-gnu/sys/timeb.h:39:12: note: declared here 39 | extern int ftime (struct timeb *__timebuf) |^ execd_commands.c: In function ‘schedule_lrmd_cmd’: execd_commands.c:389:5: error: ‘ftime’ is deprecated [-Werror=deprecated-declarations] 389 | ftime(>t_queue); | ^ """ And man page shows: SYNOPSIS #include int ftime(struct timeb *tp); DESCRIPTION NOTE: This function is deprecated, and will be removed in a future version of the GNU C library. Use clock_gettime(2) instead. I'll fix this together with other fixes, opening this bug to track the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1869751/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1870235] Re: [focal] pacemaker v2.0.3 last upstream fixes
Cherry-picks that seem to make sense after 2.0.3 release are: Fix: tools: Fix definition of curses_indented_printf. Fix: iso8601: Fix crm_time_parse_offset() to parse offset with plus sign. Log: libcrmcommon: correctly raise detail log line length Low: libcrmservice: handle child wait errors appropriately Log: libcrmservice: improve messages when waiting for child process Refactor: libcrmservice: isolate SIGCHLD handling Fix: libstonithd, tools: Fix arguments to stonith-event. Fix: libpengine: Options should be unsigned int, not long. Fix: libstonithd: Some validate arguments should be non-const. Fix: scheduler: make sure cluster-wide maintenance-mode=true overrides per-resource settings Fix: tools: Correct the crm_mon man page. There are too many fixes but mostly related to in-development refactorings so it's hard to distinguish if a fix is fixing something that exists already in v2.0.3. I preferred to be conservative and pick the ones that made more sense - core parts - and were solved right after the release (and of course didn't introduce new features and major code refactoring). A list of all commits after v2.0.3 can be seen at: https://paste.ubuntu.com/p/pGzWc2qZpB/ -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1870235 Title: [focal] pacemaker v2.0.3 last upstream fixes Status in pacemaker package in Ubuntu: In Progress Bug description: Together with fix for: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1869751 (FTBFS) This bug will also backport/cherrypick fixes released after 2.0.3 release. The correct patches are going to be defined within this bug comments. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1870235/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1870235] Re: [focal] pacemaker v2.0.3 last upstream fixes
** Description changed: Together with fix for: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1869751 (FTBFS) This bug will also backport/cherrypick fixes released after 2.0.3 - release: - - c1bc0a7f4 Merge pull request #2023 from kgaillot/fixes - f00d1120f Merge pull request #2005 from clumens/tag-fixes - 5c543bc73 Fix: xml: Add a new version of the tags schema. - d9109fb83 Fix: tools: Apply various fixes to the crm_diff man page. - 269aea44b Merge pull request #2017 from kgaillot/fixes - ad532cfff Low: fencer,libstonithd: fix Y2038 issue in fence history - ef2037126 Doc: libcrmcommon: fix doc string mistake - f0be039f9 Merge pull request #2015 from clumens/more-blanks - e2215c722 Fix: tools: One more blank line related fix for crm_mon. - ef1208197 Merge pull request #2010 from kgaillot/fixes - 4c997e61a Merge pull request #2006 from HideoYamauchi/trac4454-fix - 7cd3ecfd3 Low: crm: Fix argument order in declaration - 78db2071e Merge pull request #1999 from clumens/crm_mon-fixes - 5e3b8cdba Merge pull request #2004 from jnpkrn/build-gcc10-s390x - 4267f7fc4 Doc: Pacemaker Development: crm_str easy to forget, like its prime use - 9acf1f9b3 Build: fix compilation -Werror compilation issue with GCC 10 with s390x - 0625eb1a2 Merge pull request #1996 from kgaillot/fixes - 902e79f43 Feature: Rework how a prefix for bans is given in crm_mon. - 4860c572c Fix: tools: Move print_neg_location_prefix into options. - 398611256 Fix: tools: Use formatted output for more errors in crm_mon. - a290911ef Merge pull request #1989 from kgaillot/fixes - 7599e6d98 Build: configure: fix syntax error - 68bd2b4da Merge pull request #1953 from jnpkrn/build-fix-inkscape-1.0-beta-compat - df6c286d9 Merge pull request #1985 from kgaillot/rhbz1760669 - cdf84f849 Merge pull request #1984 from kgaillot/fixes - 38ef24516 Merge pull request #1979 from kgaillot/fixes - 403c5b1f8 Merge pull request #1978 from jnpkrn/gcc10-fno-common-fix - ea5b06fae Merge pull request #1976 from jnpkrn/fix-process-will-not-die - e0ca2a0b7 Fix: libpacemaker: Fix setting options when calling the history opt. - 3fa025298 Fix: libpacemaker: Fix handling of some operation return values. - 529ff2851 Merge pull request #1971 from clumens/crm_mon-fixes - 5b98dd71c Fix: tools: Re-enable CGI output from crm_mon. - ed6972a74 Fix: tools: Maintain a list of extra HTML headers. - c2e5d2d02 Fix: tools: Correct sec vs. msec discrepancy in stonith_admin. - bc6f54495 Merge pull request #1968 from kgaillot/fixes - f11fedd40 Refactor: libcrmcommon,libpacemaker,tools: convert pcmk__output_new() to standard return codes - 264afd724 Merge pull request #1958 from kgaillot/fixes - aa779a942 Merge pull request #1960 from yoshfuji/fix-iso8601-parser-20191217 - 33e28dcad Merge pull request #1955 from kgaillot/fixes - d671faa22 Merge pull request #1954 from aleksei-burlakov/fix-libpe_status-maintenance-mode - 47ecd21b9 Build: fix unability to build with Inkscape 1.0 beta version(s) - 4f5207a28 Fix: tools: Correct the crm_mon man page. + release. The correct patches are going to be defined within this bug comments. -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1870235 Title: [focal] pacemaker v2.0.3 last upstream fixes Status in pacemaker package in Ubuntu: In Progress Bug description: Together with fix for: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1869751 (FTBFS) This bug will also backport/cherrypick fixes released after 2.0.3 release. The correct patches are going to be defined within this bug comments. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1870235/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1638210] Re: saidar segmentation fault
There are other comments saying that the issue does not seem to be solved: https://github.com/libstatgrab/libstatgrab/issues/102#issuecomment-509715203 I'm marking this as incomplete since we still need a dump to do anything further. ** Also affects: libstatgrab (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: libstatgrab (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: libstatgrab (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: libstatgrab (Ubuntu) Status: Confirmed => Fix Released ** Changed in: libstatgrab (Ubuntu Xenial) Status: New => Incomplete ** Changed in: libstatgrab (Ubuntu Bionic) Status: New => Incomplete ** Changed in: libstatgrab (Ubuntu Eoan) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to libstatgrab in Ubuntu. https://bugs.launchpad.net/bugs/1638210 Title: saidar segmentation fault Status in libstatgrab package in Ubuntu: Fix Released Status in libstatgrab source package in Xenial: Incomplete Status in libstatgrab source package in Bionic: Incomplete Status in libstatgrab source package in Eoan: Incomplete Status in libstatgrab package in Debian: Fix Released Bug description: Erreur de segmentation (core dumped) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libstatgrab/+bug/1638210/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1869751] Re: [focal] pacemaker FTBFS because of deprecated ftime()
While some may think the fix for this is to suppress deprecated warning OR to "fix" ftime()... the actual fix for this is to start using MONOTONIC clock for the related functions: (c)rafaeldtinoco@clufocaldev:~/.../sources/ubuntu/pacemaker$ git diff HEAD diff --git a/configure.ac b/configure.ac index a4c8ae93..b7edea57 100644 --- a/configure.ac +++ b/configure.ac @@ -981,7 +981,7 @@ AC_CHECK_DECLS([CLOCK_MONOTONIC], [], [], [[ # will only be applied in 2.0.3 release and will become opt-out since # (which hopefully explains the name of the macro as it will start to # make more sense then, and the continuity is important) -CPPFLAGS="-DPCMK_TIME_EMERGENCY_CGT $CPPFLAGS" +# CPPFLAGS="-DPCMK_TIME_EMERGENCY_CGT $CPPFLAGS" dnl This solves the building issue. -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1869751 Title: [focal] pacemaker FTBFS because of deprecated ftime() Status in pacemaker package in Ubuntu: Confirmed Bug description: https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20200327 -focal-focal.html shows that pacemaker started to be FTBFS because of: """ gcc -DHAVE_CONFIG_H -I. -I../../include -DSUPPORT_REMOTE -I../../include -I../../include -I../../libltdl -I../../libltdl -DPCMK_TIME_EMERGENCY_CGT -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/heartbeat -I/usr/include/dbus-1.0 -I/usr/lib/i386-linux-gnu/dbus-1.0/include -fPIE -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -ggdb -fgnu89-inline -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wdeclaration-after-statement -Wendif-labels -Wfloat-equal -Wformat-security -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Wno-long-long -Wno-strict-aliasing -Wpointer-arith -Wwrite-strings -Wunused-but-set-variable -Wformat=2 -Wformat-nonliteral -fstack-protector-strong -Werror -c -o pacemaker_remoted-pacemaker-execd.o `test -f 'pacemaker-execd.c' || echo './'`pacemaker-execd.c execd_commands.c: In function ‘stonith_recurring_op_helper’: execd_commands.c:257:5: error: ‘ftime’ is deprecated [-Werror=deprecated-declarations] 257 | ftime(>t_queue); | ^ In file included from execd_commands.c:23: /usr/include/i386-linux-gnu/sys/timeb.h:39:12: note: declared here 39 | extern int ftime (struct timeb *__timebuf) |^ execd_commands.c: In function ‘schedule_lrmd_cmd’: execd_commands.c:389:5: error: ‘ftime’ is deprecated [-Werror=deprecated-declarations] 389 | ftime(>t_queue); | ^ """ And man page shows: SYNOPSIS #include int ftime(struct timeb *tp); DESCRIPTION NOTE: This function is deprecated, and will be removed in a future version of the GNU C library. Use clock_gettime(2) instead. I'll fix this together with other fixes, opening this bug to track the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1869751/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1869751] Re: [focal] pacemaker FTBFS because of deprecated ftime()
commit 4b8b84cce1fd57eec1f47ca44780d60c148b399d Author: Jan Pokorný Date: Fri Nov 15 16:06:57 2019 +0100 Build: restore buildability in the face of obsolete ftime(3) Since the usage of ftime(3) is purely optional and since clock_gettime(3) is mandated with POSIX 2001, we can simply look at whether CLOCK_MONOTONIC is defined to be used as an identifier for the particular clock (kind exactly suitable for this context). But due to being late in the release cycle, such a change is kept as opt-in (see configure.ac comment for details), and for compatibility stability concerns[*], also dropping some old surrounding cruft is delayed. In this form, constitutes first step out of two to restore out-of-the-box buildability with recent enough glibc, again, refer to configure.ac comment. References: https://sourceware.org/git/?p=glibc.git;a=commit;h=2b5fea833bcd0f651579afd16ed7842770ecbae1 https://src.fedoraproject.org/rpms/glibc/c/ebf75398f06dd27357d8a5321e8e5959633b8182?branch=master (for a Fedora Rawhide follow-the-upstream update that led to this discovery) [*] in case you opt-in (as described), CLOCK_MONOTONIC gets detected in time.h positively but it starts choking for whatever reason in the actual build or even in run-time, you can rescind that, or you can shortcut any checking and refrain from any time period measurements altogher with something like: env \ ac_cv_header_sys_timeb_h=no ac_cv_have_decl_CLOCK_MONOTONIC=no \ ./configure -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1869751 Title: [focal] pacemaker FTBFS because of deprecated ftime() Status in pacemaker package in Ubuntu: Confirmed Bug description: https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20200327 -focal-focal.html shows that pacemaker started to be FTBFS because of: """ gcc -DHAVE_CONFIG_H -I. -I../../include -DSUPPORT_REMOTE -I../../include -I../../include -I../../libltdl -I../../libltdl -DPCMK_TIME_EMERGENCY_CGT -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/heartbeat -I/usr/include/dbus-1.0 -I/usr/lib/i386-linux-gnu/dbus-1.0/include -fPIE -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -ggdb -fgnu89-inline -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wdeclaration-after-statement -Wendif-labels -Wfloat-equal -Wformat-security -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Wno-long-long -Wno-strict-aliasing -Wpointer-arith -Wwrite-strings -Wunused-but-set-variable -Wformat=2 -Wformat-nonliteral -fstack-protector-strong -Werror -c -o pacemaker_remoted-pacemaker-execd.o `test -f 'pacemaker-execd.c' || echo './'`pacemaker-execd.c execd_commands.c: In function ‘stonith_recurring_op_helper’: execd_commands.c:257:5: error: ‘ftime’ is deprecated [-Werror=deprecated-declarations] 257 | ftime(>t_queue); | ^ In file included from execd_commands.c:23: /usr/include/i386-linux-gnu/sys/timeb.h:39:12: note: declared here 39 | extern int ftime (struct timeb *__timebuf) |^ execd_commands.c: In function ‘schedule_lrmd_cmd’: execd_commands.c:389:5: error: ‘ftime’ is deprecated [-Werror=deprecated-declarations] 389 | ftime(>t_queue); | ^ """ And man page shows: SYNOPSIS #include int ftime(struct timeb *tp); DESCRIPTION NOTE: This function is deprecated, and will be removed in a future version of the GNU C library. Use clock_gettime(2) instead. I'll fix this together with other fixes, opening this bug to track the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1869751/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1870235] [NEW] [focal] pacemaker v2.0.3 last upstream fixes
Public bug reported: Together with fix for: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1869751 (FTBFS) This bug will also backport/cherrypick fixes released after 2.0.3 release: c1bc0a7f4 Merge pull request #2023 from kgaillot/fixes f00d1120f Merge pull request #2005 from clumens/tag-fixes 5c543bc73 Fix: xml: Add a new version of the tags schema. d9109fb83 Fix: tools: Apply various fixes to the crm_diff man page. 269aea44b Merge pull request #2017 from kgaillot/fixes ad532cfff Low: fencer,libstonithd: fix Y2038 issue in fence history ef2037126 Doc: libcrmcommon: fix doc string mistake f0be039f9 Merge pull request #2015 from clumens/more-blanks e2215c722 Fix: tools: One more blank line related fix for crm_mon. ef1208197 Merge pull request #2010 from kgaillot/fixes 4c997e61a Merge pull request #2006 from HideoYamauchi/trac4454-fix 7cd3ecfd3 Low: crm: Fix argument order in declaration 78db2071e Merge pull request #1999 from clumens/crm_mon-fixes 5e3b8cdba Merge pull request #2004 from jnpkrn/build-gcc10-s390x 4267f7fc4 Doc: Pacemaker Development: crm_str easy to forget, like its prime use 9acf1f9b3 Build: fix compilation -Werror compilation issue with GCC 10 with s390x 0625eb1a2 Merge pull request #1996 from kgaillot/fixes 902e79f43 Feature: Rework how a prefix for bans is given in crm_mon. 4860c572c Fix: tools: Move print_neg_location_prefix into options. 398611256 Fix: tools: Use formatted output for more errors in crm_mon. a290911ef Merge pull request #1989 from kgaillot/fixes 7599e6d98 Build: configure: fix syntax error 68bd2b4da Merge pull request #1953 from jnpkrn/build-fix-inkscape-1.0-beta-compat df6c286d9 Merge pull request #1985 from kgaillot/rhbz1760669 cdf84f849 Merge pull request #1984 from kgaillot/fixes 38ef24516 Merge pull request #1979 from kgaillot/fixes 403c5b1f8 Merge pull request #1978 from jnpkrn/gcc10-fno-common-fix ea5b06fae Merge pull request #1976 from jnpkrn/fix-process-will-not-die e0ca2a0b7 Fix: libpacemaker: Fix setting options when calling the history opt. 3fa025298 Fix: libpacemaker: Fix handling of some operation return values. 529ff2851 Merge pull request #1971 from clumens/crm_mon-fixes 5b98dd71c Fix: tools: Re-enable CGI output from crm_mon. ed6972a74 Fix: tools: Maintain a list of extra HTML headers. c2e5d2d02 Fix: tools: Correct sec vs. msec discrepancy in stonith_admin. bc6f54495 Merge pull request #1968 from kgaillot/fixes f11fedd40 Refactor: libcrmcommon,libpacemaker,tools: convert pcmk__output_new() to standard return codes 264afd724 Merge pull request #1958 from kgaillot/fixes aa779a942 Merge pull request #1960 from yoshfuji/fix-iso8601-parser-20191217 33e28dcad Merge pull request #1955 from kgaillot/fixes d671faa22 Merge pull request #1954 from aleksei-burlakov/fix-libpe_status-maintenance-mode 47ecd21b9 Build: fix unability to build with Inkscape 1.0 beta version(s) 4f5207a28 Fix: tools: Correct the crm_mon man page. The correct patches are going to be defined within this bug comments. ** Affects: pacemaker (Ubuntu) Importance: High Assignee: Rafael David Tinoco (rafaeldtinoco) Status: In Progress ** Changed in: pacemaker (Ubuntu) Status: New => In Progress ** Changed in: pacemaker (Ubuntu) Importance: Undecided => High ** Changed in: pacemaker (Ubuntu) Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco) -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1870235 Title: [focal] pacemaker v2.0.3 last upstream fixes Status in pacemaker package in Ubuntu: In Progress Bug description: Together with fix for: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1869751 (FTBFS) This bug will also backport/cherrypick fixes released after 2.0.3 release: c1bc0a7f4 Merge pull request #2023 from kgaillot/fixes f00d1120f Merge pull request #2005 from clumens/tag-fixes 5c543bc73 Fix: xml: Add a new version of the tags schema. d9109fb83 Fix: tools: Apply various fixes to the crm_diff man page. 269aea44b Merge pull request #2017 from kgaillot/fixes ad532cfff Low: fencer,libstonithd: fix Y2038 issue in fence history ef2037126 Doc: libcrmcommon: fix doc string mistake f0be039f9 Merge pull request #2015 from clumens/more-blanks e2215c722 Fix: tools: One more blank line related fix for crm_mon. ef1208197 Merge pull request #2010 from kgaillot/fixes 4c997e61a Merge pull request #2006 from HideoYamauchi/trac4454-fix 7cd3ecfd3 Low: crm: Fix argument order in declaration 78db2071e Merge pull request #1999 from clumens/crm_mon-fixes 5e3b8cdba Merge pull request #2004 from jnpkrn/build-gcc10-s390x 4267f7fc4 Doc: Pacemaker Development: crm_str easy to forget, like its prime use 9acf1f9b3 Build: fix compilation -Werror compilation issue with GCC 10 with s390x 0625eb1a2 Merge pull request #1996 from kgaillot/fixes 902e79f43 Featur
[Ubuntu-ha] [Bug 1828223] Re: pacemaker v2 appears to be missing log directory
Thank you for taking the time to report this bug. In an effort to keep an up-to-date and valid list of bugs to work on, I have reviewed this report to verify it still requires effort and occurs on an Ubuntu release in standard support, and it does not. It is unfortunate that we were unable to resolve this defect, however there appears to be no further action possible at this time. I am therefore moving the bug to 'Incomplete'. If you disagree or have new information, we would be grateful if you could please add a comment stating why and then change the status of the bug to 'New'. -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1828223 Title: pacemaker v2 appears to be missing log directory Status in pacemaker package in Ubuntu: Fix Released Status in pacemaker source package in Disco: Won't Fix Status in pacemaker source package in Eoan: Fix Released Status in pacemaker package in Debian: Fix Released Bug description: # journalctl -u pacemaker | grep 'logging to' May 08 12:30:49 nice-mako pacemakerd[325]: error: Directory '/var/log/pacemaker' does not exist: logging to '/var/log/pacemaker/pacemaker.log' is disabled May 08 12:30:49 nice-mako pacemaker-fenced[329]: error: Directory '/var/log/pacemaker' does not exist: logging to '/var/log/pacemaker/pacemaker.log' is disabled May 08 12:30:49 nice-mako pacemaker-based[328]: error: Directory '/var/log/pacemaker' does not exist: logging to '/var/log/pacemaker/pacemaker.log' is disabled May 08 12:30:49 nice-mako pacemaker-schedulerd[332]: error: Directory '/var/log/pacemaker' does not exist: logging to '/var/log/pacemaker/pacemaker.log' is disabled May 08 12:30:49 nice-mako pacemaker-attrd[331]: error: Directory '/var/log/pacemaker' does not exist: logging to '/var/log/pacemaker/pacemaker.log' is disabled May 08 12:30:49 nice-mako pacemaker-execd[330]: error: Directory '/var/log/pacemaker' does not exist: logging to '/var/log/pacemaker/pacemaker.log' is disabled May 08 12:30:49 nice-mako pacemaker-controld[333]: error: Directory '/var/log/pacemaker' does not exist: logging to '/var/log/pacemaker/pacemaker.log' is disabled I guess pacemaker v2 should either be configured to log to journal by default, or that directory needs to be created? or configuration changed to log to /var/log/pacemaker.log? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1828223/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1828223] Re: pacemaker v2 appears to be missing log directory
As Paride mentioned, this is already fixed in Eoan and Focal and was an issue for Disco. ** Also affects: pacemaker (Ubuntu Focal) Importance: Medium Assignee: Rafael David Tinoco (rafaeldtinoco) Status: Confirmed ** Also affects: pacemaker (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: pacemaker (Ubuntu Disco) Importance: Undecided Status: New ** Changed in: pacemaker (Ubuntu Eoan) Status: New => Fix Released ** No longer affects: pacemaker (Ubuntu Focal) ** Changed in: pacemaker (Ubuntu) Status: Confirmed => Triaged ** Changed in: pacemaker (Ubuntu) Status: Triaged => Won't Fix ** Changed in: pacemaker (Ubuntu Disco) Status: New => Won't Fix ** Changed in: pacemaker (Ubuntu) Status: Won't Fix => Fix Released ** Changed in: pacemaker (Ubuntu) Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned) ** Changed in: pacemaker (Ubuntu) Importance: Medium => Undecided -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1828223 Title: pacemaker v2 appears to be missing log directory Status in pacemaker package in Ubuntu: Fix Released Status in pacemaker source package in Disco: Won't Fix Status in pacemaker source package in Eoan: Fix Released Status in pacemaker package in Debian: Fix Released Bug description: # journalctl -u pacemaker | grep 'logging to' May 08 12:30:49 nice-mako pacemakerd[325]: error: Directory '/var/log/pacemaker' does not exist: logging to '/var/log/pacemaker/pacemaker.log' is disabled May 08 12:30:49 nice-mako pacemaker-fenced[329]: error: Directory '/var/log/pacemaker' does not exist: logging to '/var/log/pacemaker/pacemaker.log' is disabled May 08 12:30:49 nice-mako pacemaker-based[328]: error: Directory '/var/log/pacemaker' does not exist: logging to '/var/log/pacemaker/pacemaker.log' is disabled May 08 12:30:49 nice-mako pacemaker-schedulerd[332]: error: Directory '/var/log/pacemaker' does not exist: logging to '/var/log/pacemaker/pacemaker.log' is disabled May 08 12:30:49 nice-mako pacemaker-attrd[331]: error: Directory '/var/log/pacemaker' does not exist: logging to '/var/log/pacemaker/pacemaker.log' is disabled May 08 12:30:49 nice-mako pacemaker-execd[330]: error: Directory '/var/log/pacemaker' does not exist: logging to '/var/log/pacemaker/pacemaker.log' is disabled May 08 12:30:49 nice-mako pacemaker-controld[333]: error: Directory '/var/log/pacemaker' does not exist: logging to '/var/log/pacemaker/pacemaker.log' is disabled I guess pacemaker v2 should either be configured to log to journal by default, or that directory needs to be created? or configuration changed to log to /var/log/pacemaker.log? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1828223/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1825992] Re: Upgrade to version 2.0 to satisfy pcs dependency
Thank you for taking the time to report this bug. In an effort to keep an up-to-date and valid list of bugs to work on, I have reviewed this report to verify it still requires effort and occurs on an Ubuntu release in standard support, and it does not. I have marked Disco was won't fix as it was EOL in this last January 2020. Currently, for focal we have: - PCS: 0.10.4-2ubuntu1 (Debian: 0.10.4-2, Upstream: 0.10.5) - COROSYNC: 3.0.3-2ubuntu1 (Debian: 3.0.3-2 +fixes, Upstream: v3.0.3) - PACEMAKER: 2.0.3-3ubuntu1 (Debian: 2.0.3-3, Upstream: 2.0.3) AND we're still targeting crmsh tool as the "official" way of setting up PACEMAKER. We are targeting PCS to replace CRMSH in a few releases from now (crmsh is currently back in [main] while PCS is still in [universe]). With that said I'm considering this bug as fix released since Eoan. ** No longer affects: pacemaker (Ubuntu Focal) ** Changed in: pacemaker (Ubuntu) Importance: Medium => Undecided ** Changed in: pacemaker (Ubuntu Eoan) Importance: Medium => Undecided -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1825992 Title: Upgrade to version 2.0 to satisfy pcs dependency Status in pacemaker package in Ubuntu: Fix Released Status in pacemaker source package in Disco: Won't Fix Status in pacemaker source package in Eoan: Fix Released Bug description: Is there a way we could upgrade the version to 2.0? The pcs package requires a version of pacemaker that is greater than or equal to 2.0, and there is already a debian version packaged for v2. Installing the Ubuntu package for pcs will delete the pacemaker package as there is no version of pacemaker that is greater than 2.0. I can help with build/testing and packaging for 2.0 based on the existing debian deb if needed. https://pkgs.org/download/pacemaker To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1825992/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1825992] Re: Upgrade to version 2.0 to satisfy pcs dependency
** Also affects: pacemaker (Ubuntu Focal)
Importance: Medium
Assignee: Rafael David Tinoco (rafaeldtinoco)
Status: Confirmed
** Changed in: pacemaker (Ubuntu Disco)
Status: Confirmed => Won't Fix
** Changed in: pacemaker (Ubuntu Disco)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Changed in: pacemaker (Ubuntu Eoan)
Status: Confirmed => Fix Released
** Changed in: pacemaker (Ubuntu Focal)
Status: Confirmed => Fix Released
** Changed in: pacemaker (Ubuntu Focal)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Changed in: pacemaker (Ubuntu Eoan)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed to pacemaker in Ubuntu.
https://bugs.launchpad.net/bugs/1825992
Title:
Upgrade to version 2.0 to satisfy pcs dependency
Status in pacemaker package in Ubuntu:
Fix Released
Status in pacemaker source package in Disco:
Won't Fix
Status in pacemaker source package in Eoan:
Fix Released
Bug description:
Is there a way we could upgrade the version to 2.0? The pcs package
requires a version of pacemaker that is greater than or equal to 2.0,
and there is already a debian version packaged for v2. Installing the
Ubuntu package for pcs will delete the pacemaker package as there is
no version of pacemaker that is greater than 2.0.
I can help with build/testing and packaging for 2.0 based on the
existing debian deb if needed.
https://pkgs.org/download/pacemaker
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1825992/+subscriptions
___
Mailing list: https://launchpad.net/~ubuntu-ha
Post to : ubuntu-ha@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-ha
More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1627083] Re: ipt_CLUSTERIP is deprecated and it will removed soon, use xt_cluster instead
commit 92c49b6f2847546f3f938b10a2a97021774f0be3 Author: Jan Pokorný Date: Wed Dec 4 14:36:59 2019 +0100 IPaddr2: ipt_CLUSTERIP "iptables" extension not "nft" backend compatible Reference: https://lists.clusterlabs.org/pipermail/users/2019-December/026674.html (thread also sketches a future ambition for a [presumably, to revert the habit of a functional overloading] separate agent to use "xt_cluster" extension/cluster match). Signed-off-by: Jan Pokorný --- It is a well known upstream decision and it has been recently documented in v4.5.0 of "resource-agents". The following resource-agent description is about to get added to Focal when FFe: https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug/1866383 is accepted and merge is finished. ** Also affects: resource-agents (Ubuntu) Importance: Undecided Status: New ** No longer affects: strongswan (Ubuntu) ** No longer affects: pacemaker (Ubuntu) ** Changed in: resource-agents (Ubuntu) Importance: Undecided => Wishlist ** Changed in: resource-agents (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1627083 Title: ipt_CLUSTERIP is deprecated and it will removed soon, use xt_cluster instead Status in resource-agents package in Ubuntu: Confirmed Bug description: pacemaker still uses iptable's "CLUSTERIP" -- and dmesg shows a deprecation warning: [ 15.027333] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully [ 15.027464] ipt_CLUSTERIP: ipt_CLUSTERIP is deprecated and it will removed soon, use xt_cluster instead ~# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination CLUSTERIP all -- anywhere proxy.charite.de CLUSTERIP hashmode=sourceip-sourceport clustermac=EF:EE:6B:F9:7B:67 total_nodes=4 local_node=2 hash_init=0 ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: pacemaker 1.1.14-2ubuntu1.1 ProcVersionSignature: Ubuntu 4.4.0-38.57-generic 4.4.19 Uname: Linux 4.4.0-38-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 Date: Fri Sep 23 17:26:01 2016 InstallationDate: Installed on 2014-08-19 (766 days ago) InstallationMedia: Ubuntu-Server 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.3) SourcePackage: pacemaker UpgradeStatus: Upgraded to xenial on 2016-09-22 (1 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug/1627083/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1490727] Re: "Invalid IPC credentials" after corosync, pacemaker service restarts
For pacemaker, this is a duplicate of:
https://bugs.launchpad.net/bugs/1439649
So, instead of marking it as duplicate, since it had charm work, I'm
removing pacemaker from the bug and leaving this comment:
https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1439649/comments/20
"""
>From Corosync 2.4.1 Release Notes:
This release contains fix for one regression and few more smaller fixes.
"""
During 2.3.6 development the bug which is causing pacemaker to not work after
corosync configuration file is reloaded happened. Solution is ether to use this
fixed version (recommended) or as a quick workaround (for users who wants to
stay on 2.3.6 or 2.4.0) is to create file pacemaker (file name can be
arbitrary) in /etc/corosync/uidgid.d directory with following content (you can
also put same stanza into /etc/corosync/corosync.conf):
uidgid {
gid: haclient
}
"""
Anyone relying in Trusty or Xenial corosync:
corosync | 2.3.3-1ubuntu1 | trusty
corosync | 2.3.3-1ubuntu4 | trusty-updates
corosync | 2.3.5-3ubuntu1 | xenial
corosync | 2.3.5-3ubuntu2.3 | xenial-security
corosync | 2.3.5-3ubuntu2.3 | xenial-updates
should apply the mitigation above, like discovered previously by
commenters of this bug.
Note: Trusty is already EOS so I'm marking it as "won't fix".
Xenial should include the mitigation in a SRU.
"""
** No longer affects: pacemaker (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed to pacemaker in Ubuntu.
https://bugs.launchpad.net/bugs/1490727
Title:
"Invalid IPC credentials" after corosync, pacemaker service restarts
Status in Landscape Server:
Fix Released
Status in Landscape Server 15.07 series:
Fix Released
Status in Landscape Server cisco-odl series:
Fix Released
Status in hacluster package in Juju Charms Collection:
Fix Released
Bug description:
Followup from
https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1439649,
see there comments #14, #15 as it _maybe_ related to missing uidgid ACLs for
hacluster:haclient (as apparently presented by pacemaker).
FYI you can find relevant IPC resources with:
$ find /run/shm -user hacluster -group haclient -ls
To manage notifications about this bug go to:
https://bugs.launchpad.net/landscape/+bug/1490727/+subscriptions
___
Mailing list: https://launchpad.net/~ubuntu-ha
Post to : ubuntu-ha@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-ha
More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1439649] Re: Pacemaker unable to communicate with corosync on restart under lxc
** Also affects: pacemaker (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: pacemaker (Ubuntu Trusty) Importance: Undecided Status: New ** Changed in: pacemaker (Ubuntu) Status: Confirmed => Fix Released ** Also affects: pacemaker (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: pacemaker (Ubuntu Bionic) Status: New => Fix Released ** Changed in: pacemaker (Ubuntu Xenial) Status: New => Confirmed ** Changed in: pacemaker (Ubuntu Trusty) Status: New => Confirmed ** Changed in: pacemaker (Ubuntu Xenial) Importance: Undecided => High ** Changed in: pacemaker (Ubuntu Trusty) Importance: Undecided => Medium ** Changed in: pacemaker (Ubuntu Xenial) Importance: High => Medium -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1439649 Title: Pacemaker unable to communicate with corosync on restart under lxc Status in pacemaker package in Ubuntu: Fix Released Status in pacemaker source package in Trusty: Won't Fix Status in pacemaker source package in Xenial: Confirmed Status in pacemaker source package in Bionic: Fix Released Bug description: We've seen this a few times with three node clusters, all running in LXC containers; pacemaker fails to restart correctly as it can't communicate with corosync, resulting in a down cluster. Rebooting the containers resolves the issue, so suspect some sort of bad state either in corosync or pacemaker. Apr 2 11:41:32 juju-machine-4-lxc-4 pacemakerd[1033741]: notice: mcp_read_config: Configured corosync to accept connections from group 115: Library error (2) Apr 2 11:41:32 juju-machine-4-lxc-4 pacemakerd[1033741]: notice: main: Starting Pacemaker 1.1.10 (Build: 42f2063): generated-manpages agent-manpages ncurses libqb-logging libqb-ipc lha-fencing upstart nagios heartbeat corosync-native snmp libesmtp Apr 2 11:41:32 juju-machine-4-lxc-4 pacemakerd[1033741]: notice: cluster_connect_quorum: Quorum acquired Apr 2 11:41:32 juju-machine-4-lxc-4 pacemakerd[1033741]: notice: corosync_node_name: Unable to get node name for nodeid 1000 Apr 2 11:41:32 juju-machine-4-lxc-4 pacemakerd[1033741]: notice: corosync_node_name: Unable to get node name for nodeid 1001 Apr 2 11:41:32 juju-machine-4-lxc-4 pacemakerd[1033741]: notice: corosync_node_name: Unable to get node name for nodeid 1003 Apr 2 11:41:32 juju-machine-4-lxc-4 pacemakerd[1033741]: notice: corosync_node_name: Unable to get node name for nodeid 1001 Apr 2 11:41:32 juju-machine-4-lxc-4 pacemakerd[1033741]: notice: get_node_name: Defaulting to uname -n for the local corosync node name Apr 2 11:41:32 juju-machine-4-lxc-4 pacemakerd[1033741]: notice: crm_update_peer_state: pcmk_quorum_notification: Node juju-machine-4-lxc-4[1001] - state is now member (was (null)) Apr 2 11:41:32 juju-machine-4-lxc-4 pacemakerd[1033741]: notice: corosync_node_name: Unable to get node name for nodeid 1003 Apr 2 11:41:32 juju-machine-4-lxc-4 pacemakerd[1033741]: notice: crm_update_peer_state: pcmk_quorum_notification: Node (null)[1003] - state is now member (was (null)) Apr 2 11:41:32 juju-machine-4-lxc-4 crmd[1033748]: notice: main: CRM Git Version: 42f2063 Apr 2 11:41:32 juju-machine-4-lxc-4 stonith-ng[1033744]: notice: crm_cluster_connect: Connecting to cluster infrastructure: corosync Apr 2 11:41:32 juju-machine-4-lxc-4 stonith-ng[1033744]: notice: corosync_node_name: Unable to get node name for nodeid 1001 Apr 2 11:41:32 juju-machine-4-lxc-4 stonith-ng[1033744]: notice: get_node_name: Defaulting to uname -n for the local corosync node name Apr 2 11:41:32 juju-machine-4-lxc-4 attrd[1033746]: notice: crm_cluster_connect: Connecting to cluster infrastructure: corosync Apr 2 11:41:32 juju-machine-4-lxc-4 corosync[1033732]: [MAIN ] Denied connection attempt from 109:115 Apr 2 11:41:32 juju-machine-4-lxc-4 corosync[1033732]: [QB] Invalid IPC credentials (1033732-1033746). Apr 2 11:41:32 juju-machine-4-lxc-4 attrd[1033746]:error: cluster_connect_cpg: Could not connect to the Cluster Process Group API: 11 Apr 2 11:41:32 juju-machine-4-lxc-4 attrd[1033746]:error: main: HA Signon failed Apr 2 11:41:32 juju-machine-4-lxc-4 attrd[1033746]:error: main: Aborting startup Apr 2 11:41:32 juju-machine-4-lxc-4 pacemakerd[1033741]:error: pcmk_child_exit: Child process attrd (1033746) exited: Network is down (100) Apr 2 11:41:32 juju-machine-4-lxc-4 pacemakerd[1033741]: warning: pcmk_child_exit: Pacemaker child process attrd no longer wishes to be respawned. Shutting ourselves down. Apr 2 11:41:32 juju-machine-4-lxc-4 pacemakerd[1033741]: notice: pcmk_shutdown_worker: Shuting down Pacemaker Apr 2 11:41:32 juju-machine-4-lxc-4 pacemakerd[1033741]: notice:
[Ubuntu-ha] [Bug 1870069] Re: pacemaker ftbfs in focal
*** This bug is a duplicate of bug 1869751 *** https://bugs.launchpad.net/bugs/1869751 ** This bug has been marked a duplicate of bug 1869751 [focal] pacemaker FTBFS because of deprecated ftime() -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1870069 Title: pacemaker ftbfs in focal Status in pacemaker package in Ubuntu: Confirmed Bug description: seen in the second focal test rebuild https://launchpadlibrarian.net/471775801/buildlog_ubuntu-focal-amd64.pacemaker_2.0.3-3ubuntu1_BUILDING.txt.gz execd_commands.c: In function ‘stonith_recurring_op_helper’: execd_commands.c:257:5: error: ‘ftime’ is deprecated [-Werror=deprecated-declarations] 257 | ftime(>t_queue); | ^ In file included from execd_commands.c:23: /usr/include/x86_64-linux-gnu/sys/timeb.h:39:12: note: declared here 39 | extern int ftime (struct timeb *__timebuf) |^ execd_commands.c: In function ‘schedule_lrmd_cmd’: execd_commands.c:389:5: error: ‘ftime’ is deprecated [-Werror=deprecated-declarations] 389 | ftime(>t_queue); | ^ In file included from execd_commands.c:23: /usr/include/x86_64-linux-gnu/sys/timeb.h:39:12: note: declared here 39 | extern int ftime (struct timeb *__timebuf) |^ execd_commands.c: In function ‘time_diff_ms’: execd_commands.c:480:9: error: ‘ftime’ is deprecated [-Werror=deprecated-declarations] 480 | ftime(_now); | ^ In file included from execd_commands.c:23: /usr/include/x86_64-linux-gnu/sys/timeb.h:39:12: note: declared here 39 | extern int ftime (struct timeb *__timebuf) |^ execd_commands.c: In function ‘action_complete’: execd_commands.c:896:9: error: ‘ftime’ is deprecated [-Werror=deprecated-declarations] 896 | ftime(>t_rcchange); | ^ In file included from execd_commands.c:23: /usr/include/x86_64-linux-gnu/sys/timeb.h:39:12: note: declared here 39 | extern int ftime (struct timeb *__timebuf) |^ execd_commands.c: In function ‘lrmd_rsc_execute’: execd_commands.c:1428:13: error: ‘ftime’ is deprecated [-Werror=deprecated-declarations] 1428 | ftime(>t_first_run); | ^ In file included from execd_commands.c:23: /usr/include/x86_64-linux-gnu/sys/timeb.h:39:12: note: declared here 39 | extern int ftime (struct timeb *__timebuf) |^ execd_commands.c:1430:9: error: ‘ftime’ is deprecated [-Werror=deprecated-declarations] 1430 | ftime(>t_run); | ^ In file included from execd_commands.c:23: /usr/include/x86_64-linux-gnu/sys/timeb.h:39:12: note: declared here 39 | extern int ftime (struct timeb *__timebuf) |^ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1870069/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1869751] [NEW] [focal] pacemaker FTBFS because of deprecated ftime()
Public bug reported:
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20200327
-focal-focal.html
shows that pacemaker started to be FTBFS because of:
"""
gcc -DHAVE_CONFIG_H -I. -I../../include -DSUPPORT_REMOTE -I../../include
-I../../include -I../../libltdl -I../../libltdl -DPCMK_TIME_EMERGENCY_CGT
-Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/glib-2.0
-I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/libxml2
-I/usr/include/heartbeat -I/usr/include/dbus-1.0
-I/usr/lib/i386-linux-gnu/dbus-1.0/include -fPIE -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -ggdb -fgnu89-inline -Wall -Waggregate-return
-Wbad-function-cast -Wcast-align -Wdeclaration-after-statement -Wendif-labels
-Wfloat-equal -Wformat-security -Wmissing-prototypes -Wmissing-declarations
-Wnested-externs -Wno-long-long -Wno-strict-aliasing -Wpointer-arith
-Wwrite-strings -Wunused-but-set-variable -Wformat=2 -Wformat-nonliteral
-fstack-protector-strong -Werror -c -o pacemaker_remoted-pacemaker-execd.o
`test -f 'pacemaker-execd.c' || echo './'`pacemaker-execd.c
execd_commands.c: In function ‘stonith_recurring_op_helper’:
execd_commands.c:257:5: error: ‘ftime’ is deprecated
[-Werror=deprecated-declarations]
257 | ftime(>t_queue);
| ^
In file included from execd_commands.c:23:
/usr/include/i386-linux-gnu/sys/timeb.h:39:12: note: declared here
39 | extern int ftime (struct timeb *__timebuf)
|^
execd_commands.c: In function ‘schedule_lrmd_cmd’:
execd_commands.c:389:5: error: ‘ftime’ is deprecated
[-Werror=deprecated-declarations]
389 | ftime(>t_queue);
| ^
"""
And man page shows:
SYNOPSIS
#include
int ftime(struct timeb *tp);
DESCRIPTION
NOTE: This function is deprecated, and will be removed in a future
version of the GNU C library. Use clock_gettime(2) instead.
I'll fix this together with other fixes, opening this bug to track the issue.
** Affects: pacemaker (Ubuntu)
Importance: High
Assignee: Rafael David Tinoco (rafaeldtinoco)
Status: Confirmed
** Changed in: pacemaker (Ubuntu)
Status: New => Won't Fix
** Changed in: pacemaker (Ubuntu)
Status: Won't Fix => Confirmed
** Changed in: pacemaker (Ubuntu)
Importance: Undecided => High
** Changed in: pacemaker (Ubuntu)
Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco)
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed to pacemaker in Ubuntu.
https://bugs.launchpad.net/bugs/1869751
Title:
[focal] pacemaker FTBFS because of deprecated ftime()
Status in pacemaker package in Ubuntu:
Confirmed
Bug description:
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20200327
-focal-focal.html
shows that pacemaker started to be FTBFS because of:
"""
gcc -DHAVE_CONFIG_H -I. -I../../include -DSUPPORT_REMOTE -I../../include
-I../../include -I../../libltdl -I../../libltdl -DPCMK_TIME_EMERGENCY_CGT
-Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/glib-2.0
-I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/libxml2
-I/usr/include/heartbeat -I/usr/include/dbus-1.0
-I/usr/lib/i386-linux-gnu/dbus-1.0/include -fPIE -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -ggdb -fgnu89-inline -Wall -Waggregate-return
-Wbad-function-cast -Wcast-align -Wdeclaration-after-statement -Wendif-labels
-Wfloat-equal -Wformat-security -Wmissing-prototypes -Wmissing-declarations
-Wnested-externs -Wno-long-long -Wno-strict-aliasing -Wpointer-arith
-Wwrite-strings -Wunused-but-set-variable -Wformat=2 -Wformat-nonliteral
-fstack-protector-strong -Werror -c -o pacemaker_remoted-pacemaker-execd.o
`test -f 'pacemaker-execd.c' || echo './'`pacemaker-execd.c
execd_commands.c: In function ‘stonith_recurring_op_helper’:
execd_commands.c:257:5: error: ‘ftime’ is deprecated
[-Werror=deprecated-declarations]
257 | ftime(>t_queue);
| ^
In file included from execd_commands.c:23:
/usr/include/i386-linux-gnu/sys/timeb.h:39:12: note: declared here
39 | extern int ftime (struct timeb *__timebuf)
|^
execd_commands.c: In function ‘schedule_lrmd_cmd’:
execd_commands.c:389:5: error: ‘ftime’ is deprecated
[-Werror=deprecated-declarations]
389 | ftime(>t_queue);
| ^
"""
And man page shows:
SYNOPSIS
#include
int ftime(struct timeb *tp);
DESCRIPTION
NOTE: This function is deprecated, and will be removed in a future
version of the GNU C library. Use clock_gettime(2) instead.
I'll fix this together with other fixes, opening this bug to track the issue.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+sourc
[Ubuntu-ha] [Bug 1425431] Re: Pacemaker [SIGSEGV - Segmentation violation] using with Heartbeat 3.x
Thank you for taking the time to report this bug. In an effort to keep an up-to-date and valid list of bugs to work on, I have reviewed this report to verify it still requires effort and occurs on an Ubuntu release in standard support, and it does not. Judging by the existing comments, other related bugs and the pointed upstream discussion thread, it appears that the wrong lrmd was being set after upgrade and that led existing cluster to confusion when connecting to the local resource manager daemon. It is unfortunate that we were unable to resolve this defect, however there appears to be no further action possible at this time. I am therefore moving the bug to 'Incomplete'. If you disagree or have new information, we would be grateful if you could please add a comment stating why and then change the status of the bug to 'New'. ** Also affects: pacemaker (Ubuntu Trusty) Importance: Undecided Status: New ** Changed in: pacemaker (Ubuntu Trusty) Status: New => Triaged ** Changed in: pacemaker (Ubuntu) Status: Confirmed => Fix Released ** Changed in: pacemaker (Ubuntu Trusty) Status: Triaged => Incomplete -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1425431 Title: Pacemaker [SIGSEGV - Segmentation violation] using with Heartbeat 3.x Status in pacemaker package in Ubuntu: Fix Released Status in pacemaker source package in Trusty: Incomplete Bug description: According to: http://oss.clusterlabs.org/pipermail/pacemaker/2013-November/020152.html and my test case using: Pacemaker - Version: 1.1.10+git20130802-1ubuntu2.3 - Architecture: armhf Hearbeat - Version: 1:3.0.5-3.2 - Architecture: armhf Cluster-Glue- Version: 1.0.11+hg2754-1.1build1 - Architecture: armhf I got (into syslog): ccm: [4356]: info: Hostname: ccm: [4356]: info: Break tie for 2 nodes cluster ccm: [4356]: WARN: ccm_state_joined: received message with unknown cookie, just dropping ccm: [4356]: info: client (pid=4361) removed from ccm heartbeat: [4269]: WARN: Managed /usr/lib/heartbeat/crmd process 4361 killed by signal 11 [SIGSEGV - Segmentation violation]. heartbeat: [4269]: ERROR: Client /usr/lib/heartbeat/crmd (pid=4361) killed by signal 11. heartbeat: [4269]: ERROR: Respawning client "/usr/lib/heartbeat/crmd": heartbeat: [4269]: info: Starting child client "/usr/lib/heartbeat/crmd" (109,114) heartbeat: [4427]: info: Starting "/usr/lib/heartbeat/crmd" as uid 109 gid 114 (pid 4427) heartbeat: [4269]: info: the send queue length from heartbeat to client crmd is set to 1024 heartbeat: [4269]: info: killing /usr/lib/heartbeat/crmd process group 4427 with signal 15 heartbeat: [4269]: info: Core process 4273 exited. 7 remaining heartbeat: [4269]: info: Core process 4274 exited. 6 remaining heartbeat: [4269]: info: Core process 4275 exited. 5 remaining heartbeat: [4269]: info: Core process 4276 exited. 4 remaining heartbeat: [4269]: info: Core process 4277 exited. 3 remaining heartbeat: [4269]: info: Core process 4278 exited. 2 remaining then node always reboot by crmd after some time. Using Heartbeat without Pacemaker (crm no into ha.cf) no problem occur. Note that /usr/lib/heartbeat/crmd are soft links to: lrwxrwxrwx 1 root root 18 Feb 5 19:51 /usr/lib/heartbeat/attrd -> ../pacemaker/attrd lrwxrwxrwx 1 root root 16 Feb 5 19:51 /usr/lib/heartbeat/cib -> ../pacemaker/cib lrwxrwxrwx 1 root root 17 Feb 5 19:51 /usr/lib/heartbeat/crmd -> ../pacemaker/crmd lrwxrwxrwx 1 root root 20 Feb 5 19:51 /usr/lib/heartbeat/pengine -> ../pacemaker/pengine lrwxrwxrwx 1 root root 21 Feb 5 19:51 /usr/lib/heartbeat/stonithd -> ../pacemaker/stonithd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1425431/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1412831] Re: crm_mon crashed with SIGABRT in g_return_if_fail_warning()
** Also affects: pacemaker (Ubuntu Trusty) Importance: Undecided Status: New ** Changed in: pacemaker (Ubuntu Trusty) Status: New => Triaged ** Changed in: pacemaker (Ubuntu) Status: Confirmed => Fix Released ** Changed in: pacemaker (Ubuntu) Importance: Medium => Undecided ** Changed in: pacemaker (Ubuntu Trusty) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1412831 Title: crm_mon crashed with SIGABRT in g_return_if_fail_warning() Status in pacemaker package in Ubuntu: Fix Released Status in pacemaker source package in Trusty: Triaged Bug description: $ sudo crm_mon -1fA will generate a crash report. $ sudo crm_mon -1fA Last updated: Tue Jan 20 15:02:21 2015 Last change: Tue Jan 20 14:42:22 2015 via crmd on juju-nobuto-machine-46 Stack: corosync Current DC: juju-nobuto-machine-45 (1002) - partition with quorum Version: 1.1.10-42f2063 3 Nodes configured 4 Resources configured Online: [ juju-nobuto-machine-44 juju-nobuto-machine-45 juju-nobuto-machine-46 ] Clone Set: cl_ping [ping] Started: [ juju-nobuto-machine-44 juju-nobuto-machine-45 juju-nobuto-machine-46 ] Resource Group: grp_percona_cluster res_mysql_vip (ocf::heartbeat:IPaddr2): Started juju-nobuto-machine-44 Node Attributes: * Node juju-nobuto-machine-44: + pingd : 100 crm_glib_handler: Cannot wait on forked child 13386: No child processes (10) + pingd : 100 crm_glib_handler: Cannot wait on forked child 13388: No child processes (10) + pingd : 100 * Node juju-nobuto-machine-45: + pingd : 100 crm_glib_handler: Cannot wait on forked child 13390: No child processes (10) + pingd : 100 crm_glib_handler: Cannot wait on forked child 13392: No child processes (10) + pingd : 100 * Node juju-nobuto-machine-46: + pingd : 100 crm_glib_handler: Cannot wait on forked child 13394: No child processes (10) + pingd : 100 crm_glib_handler: Cannot wait on forked child 13396: No child processes (10) + pingd : 100 Migration summary: * Node juju-nobuto-machine-44: * Node juju-nobuto-machine-46: * Node juju-nobuto-machine-45: $ sudo crm configure show node $id="1000" juju-nobuto-machine-44 node $id="1001" juju-nobuto-machine-46 node $id="1002" juju-nobuto-machine-45 primitive ping ocf:pacemaker:ping \ params host_list="10.5.0.1" multiplier="100" \ op monitor interval="5s" primitive res_mysql_vip ocf:heartbeat:IPaddr2 \ params ip="10.5.100.1" cidr_netmask="16" nic="eth0" group grp_percona_cluster res_mysql_vip clone cl_ping ping \ meta interleave="true" location Ping-res_mysql_vip res_mysql_vip \ rule $id="Ping-res_mysql_vip-rule" -inf: pingd lte 0 property $id="cib-bootstrap-options" \ dc-version="1.1.10-42f2063" \ cluster-infrastructure="corosync" \ no-quorum-policy="stop" \ stonith-enabled="false" \ last-lrm-refresh="1421764942" rsc_defaults $id="rsc-options" \ resource-stickiness="100" ProblemType: Crash DistroRelease: Ubuntu 14.04 Package: pacemaker-cli-utils 1.1.10+git20130802-1ubuntu2.1 ProcVersionSignature: Ubuntu 3.13.0-40.69-generic 3.13.11.10 Uname: Linux 3.13.0-40-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.6 Architecture: amd64 CrashCounter: 1 Date: Tue Jan 20 14:54:20 2015 Ec2AMI: ami-000f Ec2AMIManifest: FIXME Ec2AvailabilityZone: nova Ec2InstanceType: m1.small Ec2Kernel: aki-0002 Ec2Ramdisk: ari-0002 ExecutablePath: /usr/sbin/crm_mon ExecutableTimestamp: 1411498637 ProcCmdline: crm_mon -1fA ProcCwd: /home/ubuntu ProcEnviron: TERM=screen PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash Signal: 6 SourcePackage: pacemaker StacktraceTop: g_return_if_fail_warning (log_domain=log_domain@entry=0x7fab566acb4e "GLib", pretty_function=pretty_function@entry=0x7fab566ba7e0 <__FUNCTION__.11709> "g_strsplit", expression=expression@entry=0x7fab56704fca "string != NULL") at /build/buildd/glib2.0-2.40.2/./glib/gmessages.c:1080 g_strsplit (string=0x0, delimiter=, max_tokens=) at /build/buildd/glib2.0-2.40.2/./glib/gstrfuncs.c:2269 print_attr_msg (node=0x7fab58af09e0, rsc_list=, attrname=0x7fab58afb5f0 "pingd", attrvalue=0x7fab58afb5d0 "100") at crm_mon.c:989 print_node_attribute (name=0x7fab58afb5f0, node_data=0x7fab58af09e0) at crm_mon.c:1042 g_list_foreach (list=, func=0x7fab5834c030 ,
[Ubuntu-ha] [Bug 1322899] Re: pacemaker init script links aren't created on upgrade
*** This bug is a duplicate of bug 1052449 *** https://bugs.launchpad.net/bugs/1052449 ** This bug has been marked a duplicate of bug 1052449 corosync hangs due to missing pacemaker shutdown scripts -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1322899 Title: pacemaker init script links aren't created on upgrade Status in pacemaker package in Ubuntu: Triaged Bug description: When upgrading my pacemaker/corosync machines from ubuntu 12.04 to 14.04, update-rc.d for pacemaker is not run, so the new pacemaker init.d script is never executed on system startup, causing corosync/pacemaker HA system to not start. When adding the new pacemaker init.d script, update-rc.d should be run, so pacemaker init.d is run to start pacemaker as needed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1322899/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1227580] Re: Monitoring in Master state doesn't always work
Thank you for taking the time to report this bug. In an effort to keep an
up-to-date and valid list of bugs to work on, I have reviewed this report
to verify it still requires effort and occurs on an Ubuntu release in
standard support, and it does not.
It is unfortunate that we were unable to resolve this defect, however
there appears to be no further action possible at this time. I am
therefore moving the bug to 'Incomplete'. If you disagree or have
new information, we would be grateful if you could please add a comment
stating why and then change the status of the bug to 'New'.
** Changed in: pacemaker (Ubuntu Precise)
Status: New => Incomplete
** Changed in: pacemaker (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed to pacemaker in Ubuntu.
https://bugs.launchpad.net/bugs/1227580
Title:
Monitoring in Master state doesn't always work
Status in pacemaker package in Ubuntu:
Fix Released
Status in pacemaker source package in Precise:
Incomplete
Bug description:
Hi
There is a bug that master/slave resources are not always monitored. It is
already fixed in pacemaker trunk, but not in libpengine3 1.1.6-2ubuntu3. I
patched lib/pengine/unpack.c
1391c1391,1395
< } else if(safe_str_eq(task, CRMD_ACTION_START)) {
---
> } else if(safe_str_eq(task, CRMD_ACTION_START) ||
> safe_str_eq(task, CRMD_ACTION_MIGRATED) ||
> safe_str_eq(task, CRMD_ACTION_PROMOTE) ||
> safe_str_eq(task, CRMD_ACTION_DEMOTE)) {
>
With this monitoring also works if resource has been promoted. This
bug can cause much trouble as a failed service wont be recognized.
Best regards
Achim
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1227580/+subscriptions
___
Mailing list: https://launchpad.net/~ubuntu-ha
Post to : ubuntu-ha@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-ha
More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1227580] Re: Monitoring in Master state doesn't always work
The mentioned patch is the following one:
commit fc03be02bf3a045babfe8233cbc99227da71d024
Author: David Vossel
Date: Fri Jun 29 11:24:52 2012 -0500
High: pengine: cl#5072 - Fixes monitor op stopping after rsc
promotion.
and was supposed to be applied to Precise.
** Also affects: pacemaker (Ubuntu Precise)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed to pacemaker in Ubuntu.
https://bugs.launchpad.net/bugs/1227580
Title:
Monitoring in Master state doesn't always work
Status in pacemaker package in Ubuntu:
Fix Released
Status in pacemaker source package in Precise:
Incomplete
Bug description:
Hi
There is a bug that master/slave resources are not always monitored. It is
already fixed in pacemaker trunk, but not in libpengine3 1.1.6-2ubuntu3. I
patched lib/pengine/unpack.c
1391c1391,1395
< } else if(safe_str_eq(task, CRMD_ACTION_START)) {
---
> } else if(safe_str_eq(task, CRMD_ACTION_START) ||
> safe_str_eq(task, CRMD_ACTION_MIGRATED) ||
> safe_str_eq(task, CRMD_ACTION_PROMOTE) ||
> safe_str_eq(task, CRMD_ACTION_DEMOTE)) {
>
With this monitoring also works if resource has been promoted. This
bug can cause much trouble as a failed service wont be recognized.
Best regards
Achim
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1227580/+subscriptions
___
Mailing list: https://launchpad.net/~ubuntu-ha
Post to : ubuntu-ha@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-ha
More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1052449] Re: corosync hangs due to missing pacemaker shutdown scripts
I'm marking Precise and Trusty as affected. The suggested fix is currently implemented by Xenial already: mcp/pacemaker.in: ... # Required-Start: $network corosync # Should-Start: $syslog # Required-Stop:$network corosync ... ** Also affects: pacemaker (Ubuntu Precise) Importance: Undecided Status: New ** Also affects: pacemaker (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: pacemaker (Ubuntu Trusty) Importance: Undecided Status: New ** Changed in: pacemaker (Ubuntu Xenial) Status: New => Fix Released ** Changed in: pacemaker (Ubuntu Trusty) Status: New => Confirmed ** Changed in: pacemaker (Ubuntu Precise) Status: New => Confirmed ** Changed in: pacemaker (Ubuntu) Status: Triaged => Fix Released ** Changed in: pacemaker (Ubuntu) Importance: High => Undecided ** Changed in: pacemaker (Ubuntu Trusty) Status: Confirmed => Triaged ** Changed in: pacemaker (Ubuntu Precise) Status: Confirmed => Triaged -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1052449 Title: corosync hangs due to missing pacemaker shutdown scripts Status in pacemaker package in Ubuntu: Fix Released Status in pacemaker source package in Precise: Triaged Status in pacemaker source package in Trusty: Triaged Status in pacemaker source package in Xenial: Fix Released Bug description: The pacemaker package installs the right init script but doesn't link it to the according runlevels. If corosync is activated and started on the system this leads to a hanging shutdown / reboot because corosync only ends if pacemaker is stopped beforehand. In addition to this the pacemaker daemon has to start after corosync but has to stop before corosync. A possible solution would be to link the init script accordingly an enable it throug /etc/default/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1052449/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1049037] Re: Pacemaker 1.1.6 VirtualDomain OCF wrong timeout handle on shutdown
Fix was already included in current pacemaker version by patch: commit fcfe6fe522138343e4138248829926700fac213e Author: Yan Gao Date: Mon Oct 17 11:19:01 2011 +0800 Medium: crmd: Send out all of the meta parameters to lrmd for stop actions So I'm flagging this as "Fix Released" as it does not affect current supported versions of pacemaker. ** Changed in: pacemaker (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1049037 Title: Pacemaker 1.1.6 VirtualDomain OCF wrong timeout handle on shutdown Status in pacemaker package in Ubuntu: Fix Released Bug description: Pacemaker 1.1.6 included in current LTS has a bug which causes VirtualDomain to fail upon VM shutdown. Full thread with explaination here: http://www.gossamer-threads.com/lists/linuxha/pacemaker/78969 it would be great if either the patch is backported or Pacemaker upgraded into LTS. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1049037/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 955164] Re: PostgreSQL resource agent has wrong default paths
Thank you for taking the time to report this bug. In an effort to keep an up-to-date and valid list of bugs to work on, I have reviewed this report to verify it still requires effort and occurs on an Ubuntu release in standard support, and it does not. It is unfortunate that we were unable to resolve this defect, however there appears to be no further action possible at this time. I am therefore moving the bug to 'Incomplete'. If you disagree or have new information, we would be grateful if you could please add a comment stating why and then change the status of the bug to 'New'. Observation: The correct affected package for this bug is resource-agents: (k)rafaeldtinoco@clufocal01:~$ dpkg -L resource-agents | grep -i pgsql /usr/lib/ocf/resource.d/heartbeat/pgsql and I'm opening a generic bug to check ALL resource agents paths existence. ** Also affects: resource-agents (Ubuntu) Importance: Undecided Status: New ** No longer affects: pacemaker (Ubuntu) ** Also affects: resource-agents (Ubuntu Precise) Importance: Undecided Status: New ** Changed in: resource-agents (Ubuntu Precise) Status: New => Incomplete ** Changed in: resource-agents (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/955164 Title: PostgreSQL resource agent has wrong default paths Status in resource-agents package in Ubuntu: Invalid Status in resource-agents source package in Precise: Incomplete Bug description: The pgsql resource agent has default paths which don't match those used by the Ubuntu postgresql package In the resource agent: * The default configuration file is /etc/postgresql/9.1/main/postgresql.conf * The default loction of pg_ctl is /usr/lib/postgresql/9.1/bin/pg_ctl * The default data directory is given as /var/lib/pgsql/data This causes Pacemaker to be unable to start the postgresql server, and the following errors in /var/log/syslog: Mar 14 14:51:38 OB1 pgsql[3533]: ERROR: Configuration file /var/lib/pgsql/data/postgresql.conf doesn't exist Mar 14 14:51:38 OB1 pgsql[3533]: ERROR: Setup problem: couldn't find command: /usr/bin/pg_ctl The problem is in the file /usr/lib/ocf/resource.d/heartbeat/pgsql The following patch fixes these problems: = --- pgsql.old 2012-03-14 15:17:09.123507205 + +++ pgsql 2012-03-14 15:19:37.521641615 + @@ -45,13 +45,13 @@ } # Defaults -OCF_RESKEY_pgctl_default=/usr/bin/pg_ctl +OCF_RESKEY_pgctl_default=/usr/lib/postgresql/9.1/bin/pg_ctl OCF_RESKEY_psql_default=/usr/bin/psql -OCF_RESKEY_pgdata_default=/var/lib/pgsql/data +OCF_RESKEY_pgdata_default=/var/lib/postgresql/9.1/main OCF_RESKEY_pgdba_default=postgres OCF_RESKEY_pghost_default="" OCF_RESKEY_pgport_default=5432 -OCF_RESKEY_config_default="" +OCF_RESKEY_config_default=/etc/postgresql/9.1/main/postgresql.conf OCF_RESKEY_start_opt_default="" OCF_RESKEY_pgdb_default=template1 OCF_RESKEY_logfile_default=/dev/null = To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug/955164/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1869622] Re: [focal] corosync v3.0.3 last upstream fixes
** Changed in: corosync (Ubuntu) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to corosync in Ubuntu. https://bugs.launchpad.net/bugs/1869622 Title: [focal] corosync v3.0.3 last upstream fixes Status in corosync package in Ubuntu: In Progress Bug description: Together with fixes for: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1437359 https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1677684 This bug will also backport/cherrypick the following post release fixes: -> c631951e icmap: icmap_init_r() leaks if trie_create() fails = fix -> ca320bea votequorum: set wfa status only on startup = fix -> 5f543465 quorumtool: exit on invalid expected votes = fix -> 0c16442f votequorum: Change check of expected_votes = fix -> 8ce65bf9 votequorum: Reflect runtime change of 2Node to WFA = fix -> 89b0d62f stats: Check return code of stats_map_get = fix -> 56ee8503 quorumtool: Assert copied string length= assert -> 1fb095b0 notifyd: Check cmap_track_add result = assert -> 8ff7760c cmapctl: Free bin_value on error = fix -> 35c312f8 votequorum: Assert copied strings length = assert -> 29109683 totemknet: Assert strcpy length assert = assert -> 0c118d8f totemknet: Check result of fcntl O_NONBLOCK call = assert -> a24cbad5 totemconfig: Initialize warnings variable = build fix -> 74eed54a sync: Assert sync_callbacks.name length= assert -> 380b744e totemknet: Don't mix corosync and knet error codes = fix -> 624b6a47 stats: Assert value_len when value is needed = assert -> 09f6d34a logconfig: Remove double free of value = fix -> efe48120 totemconfig: Free leaks found by coverity = fix To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1869622/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1677684] Re: /usr/bin/corosync-blackbox: 34: /usr/bin/corosync-blackbox: qb-blackbox: not found
BUG: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1869622 PPA: https://launchpad.net/~ubuntu-server-ha/+archive/ubuntu/staging ** Changed in: corosync (Ubuntu Focal) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to corosync in Ubuntu. https://bugs.launchpad.net/bugs/1677684 Title: /usr/bin/corosync-blackbox: 34: /usr/bin/corosync-blackbox: qb- blackbox: not found Status in corosync package in Ubuntu: In Progress Status in corosync source package in Trusty: Won't Fix Status in corosync source package in Xenial: Confirmed Status in corosync source package in Zesty: Won't Fix Status in corosync source package in Bionic: Confirmed Status in corosync source package in Disco: Won't Fix Status in corosync source package in Eoan: Confirmed Status in corosync source package in Focal: In Progress Bug description: [Environment] Ubuntu Xenial 16.04 Amd64 [Test Case] 1) sudo apt-get install corosync 2) sudo corosync-blackbox. root@juju-niedbalski-xenial-machine-5:/home/ubuntu# dpkg -L corosync |grep black /usr/bin/corosync-blackbox Expected results: corosync-blackbox runs OK. Current results: $ sudo corosync-blackbox /usr/bin/corosync-blackbox: 34: /usr/bin/corosync-blackbox: qb-blackbox: not found [Impact] * Cannot run corosync-blackbox [Regression Potential] * None identified. [Fix] Make the package dependant of libqb-dev root@juju-niedbalski-xenial-machine-5:/home/ubuntu# dpkg -L libqb-dev | grep qb-bl /usr/sbin/qb-blackbox To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1677684/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1869622] Re: [focal] corosync v3.0.3 last upstream fixes
For the 2 fixes: LP: #1437359 LP: #1677684 I have submitted to upstream the following merge request: https://salsa.debian.org/ha-team/corosync/-/merge_requests/2 -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to corosync in Ubuntu. https://bugs.launchpad.net/bugs/1869622 Title: [focal] corosync v3.0.3 last upstream fixes Status in corosync package in Ubuntu: Confirmed Bug description: Together with fixes for: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1437359 https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1677684 This bug will also backport/cherrypick the following post release fixes: -> c631951e icmap: icmap_init_r() leaks if trie_create() fails = fix -> ca320bea votequorum: set wfa status only on startup = fix -> 5f543465 quorumtool: exit on invalid expected votes = fix -> 0c16442f votequorum: Change check of expected_votes = fix -> 8ce65bf9 votequorum: Reflect runtime change of 2Node to WFA = fix -> 89b0d62f stats: Check return code of stats_map_get = fix -> 56ee8503 quorumtool: Assert copied string length= assert -> 1fb095b0 notifyd: Check cmap_track_add result = assert -> 8ff7760c cmapctl: Free bin_value on error = fix -> 35c312f8 votequorum: Assert copied strings length = assert -> 29109683 totemknet: Assert strcpy length assert = assert -> 0c118d8f totemknet: Check result of fcntl O_NONBLOCK call = assert -> a24cbad5 totemconfig: Initialize warnings variable = build fix -> 74eed54a sync: Assert sync_callbacks.name length= assert -> 380b744e totemknet: Don't mix corosync and knet error codes = fix -> 624b6a47 stats: Assert value_len when value is needed = assert -> 09f6d34a logconfig: Remove double free of value = fix -> efe48120 totemconfig: Free leaks found by coverity = fix To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1869622/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1869622] Re: [focal] corosync v3.0.3 last upstream fixes
** Description changed: Together with fixes for: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1437359 https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1677684 This bug will also backport/cherrypick the following post release fixes: - -> c631951e icmap: icmap_init_r() leaks if trie_create() fails = coverity fix - -> ca320bea votequorum: set wfa status only on startup = fix for corner case - -> 5f543465 quorumtool: exit on invalid expected votes = fix - -> 0c16442f votequorum: Change check of expected_votes = fix - -> 8ce65bf9 votequorum: Reflect runtime change of 2Node to WFA = fix - -> 89b0d62f stats: Check return code of stats_map_get = fix - -> 56ee8503 quorumtool: Assert copied string length = assert (better support) - -> 1fb095b0 notifyd: Check cmap_track_add result = assert (better support) - -> 8ff7760c cmapctl: Free bin_value on error (fix) - -> 35c312f8 votequorum: Assert copied strings length = assert (better support) - -> 29109683 totemknet: Assert strcpy length assert (better support) - -> 0c118d8f totemknet: Check result of fcntl O_NONBLOCK call - -> a24cbad5 totemconfig: Initialize warnings variable = build fix - -> 74eed54a sync: Assert sync_callbacks.name length = assert (better support) - -> 380b744e totemknet: Don't mix corosync and knet error codes = fix - -> 624b6a47 stats: Assert value_len when value is needed = assert (bet support) - -> 09f6d34a logconfig: Remove double free of value = fix - -> efe48120 totemconfig: Free leaks found by coverity = fix + -> c631951e icmap: icmap_init_r() leaks if trie_create() fails = fix + -> ca320bea votequorum: set wfa status only on startup = fix + -> 5f543465 quorumtool: exit on invalid expected votes = fix + -> 0c16442f votequorum: Change check of expected_votes = fix + -> 8ce65bf9 votequorum: Reflect runtime change of 2Node to WFA = fix + -> 89b0d62f stats: Check return code of stats_map_get = fix + -> 56ee8503 quorumtool: Assert copied string length= assert + -> 1fb095b0 notifyd: Check cmap_track_add result = assert + -> 8ff7760c cmapctl: Free bin_value on error = fix + -> 35c312f8 votequorum: Assert copied strings length = assert + -> 29109683 totemknet: Assert strcpy length assert = assert + -> 0c118d8f totemknet: Check result of fcntl O_NONBLOCK call = assert + -> a24cbad5 totemconfig: Initialize warnings variable = build fix + -> 74eed54a sync: Assert sync_callbacks.name length= assert + -> 380b744e totemknet: Don't mix corosync and knet error codes = fix + -> 624b6a47 stats: Assert value_len when value is needed = assert + -> 09f6d34a logconfig: Remove double free of value = fix + -> efe48120 totemconfig: Free leaks found by coverity = fix -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to corosync in Ubuntu. https://bugs.launchpad.net/bugs/1869622 Title: [focal] corosync v3.0.3 last upstream fixes Status in corosync package in Ubuntu: Confirmed Bug description: Together with fixes for: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1437359 https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1677684 This bug will also backport/cherrypick the following post release fixes: -> c631951e icmap: icmap_init_r() leaks if trie_create() fails = fix -> ca320bea votequorum: set wfa status only on startup = fix -> 5f543465 quorumtool: exit on invalid expected votes = fix -> 0c16442f votequorum: Change check of expected_votes = fix -> 8ce65bf9 votequorum: Reflect runtime change of 2Node to WFA = fix -> 89b0d62f stats: Check return code of stats_map_get = fix -> 56ee8503 quorumtool: Assert copied string length= assert -> 1fb095b0 notifyd: Check cmap_track_add result = assert -> 8ff7760c cmapctl: Free bin_value on error = fix -> 35c312f8 votequorum: Assert copied strings length = assert -> 29109683 totemknet: Assert strcpy length assert = assert -> 0c118d8f totemknet: Check result of fcntl O_NONBLOCK call = assert -> a24cbad5 totemconfig: Initialize warnings variable = build fix -> 74eed54a sync: Assert sync_callbacks.name length= assert -> 380b744e totemknet: Don't mix corosync and knet error codes = fix -> 624b6a47 stats: Assert value_len when value is needed = assert -> 09f6d34a logconfig: Remove double free of value = fix -> efe48120 totemconfig: Free leaks found by coverity = fix To manage notifications about this bug go to:
[Ubuntu-ha] [Bug 1869622] [NEW] [focal] corosync v3.0.3 last upstream fixes
Public bug reported:
Apart from fixes for:
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1437359
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1677684
This bug will also backport/cherrypick the following post release fixes:
-> c631951e icmap: icmap_init_r() leaks if trie_create() fails = coverity fix
-> ca320bea votequorum: set wfa status only on startup = fix for corner case
-> 5f543465 quorumtool: exit on invalid expected votes = fix
-> 0c16442f votequorum: Change check of expected_votes = fix
-> 8ce65bf9 votequorum: Reflect runtime change of 2Node to WFA = fix
-> 89b0d62f stats: Check return code of stats_map_get = fix
-> 56ee8503 quorumtool: Assert copied string length = assert (better support)
-> 1fb095b0 notifyd: Check cmap_track_add result = assert (better support)
-> 8ff7760c cmapctl: Free bin_value on error (fix)
-> 35c312f8 votequorum: Assert copied strings length = assert (better support)
-> 29109683 totemknet: Assert strcpy length assert (better support)
-> 0c118d8f totemknet: Check result of fcntl O_NONBLOCK call
-> a24cbad5 totemconfig: Initialize warnings variable = build fix
-> 74eed54a sync: Assert sync_callbacks.name length = assert (better support)
-> 380b744e totemknet: Don't mix corosync and knet error codes = fix
-> 624b6a47 stats: Assert value_len when value is needed = assert (bet support)
-> 09f6d34a logconfig: Remove double free of value = fix
-> efe48120 totemconfig: Free leaks found by coverity = fix
** Affects: corosync (Ubuntu)
Importance: High
Assignee: Rafael David Tinoco (rafaeldtinoco)
Status: Confirmed
** Changed in: corosync (Ubuntu)
Status: New => Confirmed
** Changed in: corosync (Ubuntu)
Importance: Undecided => High
** Changed in: corosync (Ubuntu)
Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco)
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed to corosync in Ubuntu.
https://bugs.launchpad.net/bugs/1869622
Title:
[focal] corosync v3.0.3 last upstream fixes
Status in corosync package in Ubuntu:
Confirmed
Bug description:
Apart from fixes for:
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1437359
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1677684
This bug will also backport/cherrypick the following post release
fixes:
-> c631951e icmap: icmap_init_r() leaks if trie_create() fails = coverity fix
-> ca320bea votequorum: set wfa status only on startup = fix for corner case
-> 5f543465 quorumtool: exit on invalid expected votes = fix
-> 0c16442f votequorum: Change check of expected_votes = fix
-> 8ce65bf9 votequorum: Reflect runtime change of 2Node to WFA = fix
-> 89b0d62f stats: Check return code of stats_map_get = fix
-> 56ee8503 quorumtool: Assert copied string length = assert (better support)
-> 1fb095b0 notifyd: Check cmap_track_add result = assert (better support)
-> 8ff7760c cmapctl: Free bin_value on error (fix)
-> 35c312f8 votequorum: Assert copied strings length = assert (better
support)
-> 29109683 totemknet: Assert strcpy length assert (better support)
-> 0c118d8f totemknet: Check result of fcntl O_NONBLOCK call
-> a24cbad5 totemconfig: Initialize warnings variable = build fix
-> 74eed54a sync: Assert sync_callbacks.name length = assert (better support)
-> 380b744e totemknet: Don't mix corosync and knet error codes = fix
-> 624b6a47 stats: Assert value_len when value is needed = assert (bet
support)
-> 09f6d34a logconfig: Remove double free of value = fix
-> efe48120 totemconfig: Free leaks found by coverity = fix
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1869622/+subscriptions
___
Mailing list: https://launchpad.net/~ubuntu-ha
Post to : ubuntu-ha@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-ha
More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1437359] Re: A PIDFILE is double-defined for the corosync-notifyd init script
** Tags added: server-triage-discuss -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to corosync in Ubuntu. https://bugs.launchpad.net/bugs/1437359 Title: A PIDFILE is double-defined for the corosync-notifyd init script Status in corosync package in Ubuntu: In Progress Status in corosync source package in Trusty: Won't Fix Status in corosync source package in Xenial: Triaged Status in corosync source package in Bionic: Triaged Status in corosync source package in Disco: Won't Fix Status in corosync source package in Eoan: Triaged Status in corosync source package in Focal: In Progress Bug description: A /etc/init.d/corosync-notifyd contains two definitions for the PIDFILE: > PIDFILE=/var/run/$NAME.pid > SCRIPTNAME=/etc/init.d/$NAME > PIDFILE=/var/run/corosync.pid The first one is correct and the second one is wrong as it refers to the corosync service's pidfile instead The corosync package version is 2.3.3-1ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1437359/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1340172] Re: [OSCI] Add mamange/unmanage blocks to corosync init scripts
Thank you for taking the time to report this bug. In an effort to keep an
up-to-date and valid list of bugs to work on, I have reviewed this report
to verify it still requires effort and occurs on an Ubuntu release in
standard support, and it does not.
Unfortunately this bug is old for us to consider having an sysv-compatible
option to put the cluster into maintenance mode. Corosync is also being managed,
for sometime now, by systemd so this particular change wouldn't make much sense.
IMHO this type of cluster change should be done by the cluster administrator in
specific tools like crmsh, pcs, and not in an init script.
It is unfortunate that we were unable to resolve this defect, however
there appears to be no further action possible at this time. I am
therefore moving the bug to 'Incomplete'. If you disagree or have
new information, we would be grateful if you could please add a comment
stating why and then change the status of the bug to 'New'.
** Also affects: corosync (Ubuntu Precise)
Importance: Undecided
Status: New
** Changed in: corosync (Ubuntu Precise)
Status: New => Incomplete
** Changed in: corosync (Ubuntu)
Status: Triaged => Won't Fix
** Changed in: corosync (Ubuntu)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Changed in: corosync (Ubuntu Precise)
Status: Incomplete => Won't Fix
** Changed in: corosync (Ubuntu)
Importance: High => Undecided
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed to corosync in Ubuntu.
https://bugs.launchpad.net/bugs/1340172
Title:
[OSCI] Add mamange/unmanage blocks to corosync init scripts
Status in Fuel for OpenStack:
Fix Released
Status in corosync package in Ubuntu:
Won't Fix
Status in corosync source package in Precise:
Won't Fix
Bug description:
Please add manage and unmanage fucntions to corosync init scripts'
restart actions for both Centos and Ubuntu
Here is patch for centos
--- corosync-1.4.6/init/generic.in2013-05-29 18:33:27.0 +0400
+++ corosync-1.4.6.new/init/generic.in2014-07-10 16:34:27.127641857
+0400
@@ -70,6 +70,50 @@
pidof -c -o $$ -o $PPID -o %PPID "${1##*/}"
}
+pcmk_maintance() {
+ which cibadmin 1>/dev/null 2>/dev/null
+
+ if [ "${?}" -gt "0" ]; then
+return 0
+ fi
+
+ pcmk_retry="30"
+ pcmk_maintance="${1}"
+ pcmk_sleep="1"
+
+ if [ "${pcmk_maintance}" = "" ]; then
+pcmk_maintance="true"
+ fi
+
+ while [ "${pcmk_retry}" -gt "0" ]; do
+cat <
+
+
+
+
+
+
+
+
+
+
+
+
+EOF
+
+if [ "${?}" -eq "0" ]; then
+ break
+fi
+
+echo "Pacemaker connection failed! Retries left: ${pcmk_retry}"
+pcmk_retry="$((pcmk_retry - 1))"
+sleep "${pcmk_sleep}"
+
+ done
+}
+
cluster_disabled_at_boot()
{
if grep -q nocluster /proc/cmdline && \
@@ -150,8 +194,13 @@
restart()
{
+ status $prog
+ if [ $? -eq 0 ]; then
+ pcmk_maintance true
+ fi
stop
start
+ pcmk_maintance false
}
rtrn=0
===
And patch for ubuntu
===
--- debian/corosync.init 2011-08-24 11:27:27.0 +0400
+++ debian.new/corosync.init 2014-07-10 16:47:12.823624121 +0400
@@ -39,6 +39,50 @@
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions
+pcmk_maintance() {
+ which cibadmin 1>/dev/null 2>/dev/null
+
+ if [ "${?}" -gt "0" ]; then
+return 0
+ fi
+
+ pcmk_retry="30"
+ pcmk_maintance="${1}"
+ pcmk_sleep="1"
+
+ if [ "${pcmk_maintance}" = "" ]; then
+pcmk_maintance="true"
+ fi
+
+ while [ "${pcmk_retry}" -gt "0" ]; do
+cat <
+
+
+
+
+
+
+
+
+
+
+
+
+EOF
+
+if [ "${?}" -eq "0" ]; then
+ break
+fi
+
+echo "Pacemaker connection failed! Retries left: ${pcmk_retry}"
+pcmk_retry="$((pcmk_retry - 1))"
+sleep "${pcmk_sleep}"
+
+ done
+}
+
#
# Function that starts the daemon/service
#
@@ -95,6 +139,10 @@
;;
restart|force-reload)
log_daemon_msg "Restarting $DESC" &
[Ubuntu-ha] [Bug 1677684] Re: /usr/bin/corosync-blackbox: 34: /usr/bin/corosync-blackbox: qb-blackbox: not found
This issue still exists and should be fixed. I'm putting together with some other SRUs so all of them are done at once. Thanks @niedbalski for bringing up this issue. I'll fix Ubuntu Focal for now and try to get along with the needed SRUs. ** Changed in: corosync (Ubuntu Trusty) Assignee: Jorge Niedbalski (niedbalski) => (unassigned) ** Changed in: corosync (Ubuntu) Assignee: Jorge Niedbalski (niedbalski) => (unassigned) ** Changed in: corosync (Ubuntu Zesty) Assignee: Jorge Niedbalski (niedbalski) => (unassigned) ** Changed in: corosync (Ubuntu Xenial) Assignee: Jorge Niedbalski (niedbalski) => (unassigned) ** Changed in: corosync (Ubuntu) Importance: Medium => Undecided ** Changed in: corosync (Ubuntu Zesty) Importance: Medium => Undecided ** Changed in: corosync (Ubuntu Trusty) Importance: Medium => Undecided ** Changed in: corosync (Ubuntu Xenial) Importance: Medium => Undecided ** Also affects: corosync (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: corosync (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: corosync (Ubuntu Focal) Importance: Undecided Status: Incomplete ** Also affects: corosync (Ubuntu Disco) Importance: Undecided Status: New ** Changed in: corosync (Ubuntu Focal) Status: Incomplete => Confirmed ** Changed in: corosync (Ubuntu Eoan) Status: New => Confirmed ** Changed in: corosync (Ubuntu Disco) Status: New => Won't Fix ** Changed in: corosync (Ubuntu Bionic) Status: New => Confirmed ** Changed in: corosync (Ubuntu Zesty) Status: Incomplete => Won't Fix ** Changed in: corosync (Ubuntu Xenial) Status: Incomplete => Confirmed ** Changed in: corosync (Ubuntu Trusty) Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to corosync in Ubuntu. https://bugs.launchpad.net/bugs/1677684 Title: /usr/bin/corosync-blackbox: 34: /usr/bin/corosync-blackbox: qb- blackbox: not found Status in corosync package in Ubuntu: Confirmed Status in corosync source package in Trusty: Won't Fix Status in corosync source package in Xenial: Confirmed Status in corosync source package in Zesty: Won't Fix Status in corosync source package in Bionic: Confirmed Status in corosync source package in Disco: Won't Fix Status in corosync source package in Eoan: Confirmed Status in corosync source package in Focal: Confirmed Bug description: [Environment] Ubuntu Xenial 16.04 Amd64 [Test Case] 1) sudo apt-get install corosync 2) sudo corosync-blackbox. root@juju-niedbalski-xenial-machine-5:/home/ubuntu# dpkg -L corosync |grep black /usr/bin/corosync-blackbox Expected results: corosync-blackbox runs OK. Current results: $ sudo corosync-blackbox /usr/bin/corosync-blackbox: 34: /usr/bin/corosync-blackbox: qb-blackbox: not found [Impact] * Cannot run corosync-blackbox [Regression Potential] * None identified. [Fix] Make the package dependant of libqb-dev root@juju-niedbalski-xenial-machine-5:/home/ubuntu# dpkg -L libqb-dev | grep qb-bl /usr/sbin/qb-blackbox To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1677684/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1437359] Re: A PIDFILE is double-defined for the corosync-notifyd init script
(c)rafaeldtinoco@clusterdev:~/.../sources/ubuntu/corosync$ git diff HEAD diff --git a/debian/corosync-notifyd.init b/debian/corosync-notifyd.init index c908618..837e48a 100644 --- a/debian/corosync-notifyd.init +++ b/debian/corosync-notifyd.init @@ -21,7 +21,6 @@ NAME=corosync-notifyd DAEMON=/usr/sbin/$NAME PIDFILE=/var/run/$NAME.pid SCRIPTNAME=/etc/init.d/$NAME -PIDFILE=/var/run/corosync.pid RARUNDIR=/var/run/resource-agents # Exit if the package is not installed If anyone faces this issue, just remove the second PIDFILE as it appears to be a leftover. I'll fix this and point this out to Debian as it also faces the same issue. NEVERTHELESS, remember that this issue would only exist if you are using the "sysv" scripts OR the sysv-generator (making systemd to control the service through sysv scripts). All others are probably relying in systemd to start/stop/monitor corosync daemon (/lib/systemd/system/corosync.service). -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to corosync in Ubuntu. https://bugs.launchpad.net/bugs/1437359 Title: A PIDFILE is double-defined for the corosync-notifyd init script Status in corosync package in Ubuntu: In Progress Status in corosync source package in Trusty: Won't Fix Status in corosync source package in Xenial: Triaged Status in corosync source package in Bionic: Triaged Status in corosync source package in Disco: Won't Fix Status in corosync source package in Eoan: Triaged Status in corosync source package in Focal: In Progress Bug description: A /etc/init.d/corosync-notifyd contains two definitions for the PIDFILE: > PIDFILE=/var/run/$NAME.pid > SCRIPTNAME=/etc/init.d/$NAME > PIDFILE=/var/run/corosync.pid The first one is correct and the second one is wrong as it refers to the corosync service's pidfile instead The corosync package version is 2.3.3-1ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1437359/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1654403] Re: Race condition in hacluster charm that leaves pacemaker down
** Also affects: corosync (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: corosync (Ubuntu Xenial) Status: New => Incomplete ** Changed in: corosync (Ubuntu) Status: Incomplete => Fix Released -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to corosync in Ubuntu. https://bugs.launchpad.net/bugs/1654403 Title: Race condition in hacluster charm that leaves pacemaker down Status in OpenStack hacluster charm: Fix Released Status in corosync package in Ubuntu: Fix Released Status in corosync source package in Xenial: Incomplete Status in hacluster package in Juju Charms Collection: Invalid Bug description: Symptom: one or more hacluster nodes are left in an executing state. Observing the process list on the affected nodes the command 'crm node list' is in an infinite loop and pacemaker is not started. On nodes that complete the crm node list and other crm commands pacemaker is started. See the artefacts from this run: https://openstack-ci-reports.ubuntu.com/artifacts/test_charm_pipeline/openstack/charm-percona-cluster/417131/1/1873/index.html Hypothesis: There is a race that leads to crm node list being executed before pacemaker is started. It is also possible that something causes pacemaker to fail to start. Suggest a check for pacemaker heath before any crm commands are run. To manage notifications about this bug go to: https://bugs.launchpad.net/charm-hacluster/+bug/1654403/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1437359] Re: A PIDFILE is double-defined for the corosync-notifyd init script
Okay, this is a very simple fix but it is tricky... mainly because .. possibly 99% of the users of this package are using systemd and the corosync service unit file... which does not face this issue. I'm not entirely sure a SRU is the right thing to do on all affected Ubuntu versions (Xenial, Bionic, Eoan). Will discuss this with the server team. Meanwhile, fixing Focal seems appropriate just because its not released yet ... :\ but I'll keep this "on the hand" until I have more fixes so I do the SRU all at once. ** Changed in: corosync (Ubuntu Focal) Status: Triaged => In Progress -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to corosync in Ubuntu. https://bugs.launchpad.net/bugs/1437359 Title: A PIDFILE is double-defined for the corosync-notifyd init script Status in corosync package in Ubuntu: In Progress Status in corosync source package in Trusty: Won't Fix Status in corosync source package in Xenial: Triaged Status in corosync source package in Bionic: Triaged Status in corosync source package in Disco: Won't Fix Status in corosync source package in Eoan: Triaged Status in corosync source package in Focal: In Progress Bug description: A /etc/init.d/corosync-notifyd contains two definitions for the PIDFILE: > PIDFILE=/var/run/$NAME.pid > SCRIPTNAME=/etc/init.d/$NAME > PIDFILE=/var/run/corosync.pid The first one is correct and the second one is wrong as it refers to the corosync service's pidfile instead The corosync package version is 2.3.3-1ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1437359/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1437359] Re: A PIDFILE is double-defined for the corosync-notifyd init script
** Also affects: corosync (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: corosync (Ubuntu Focal) Importance: Undecided Assignee: Rafael David Tinoco (rafaeldtinoco) Status: Triaged ** Also affects: corosync (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: corosync (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: corosync (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: corosync (Ubuntu Eoan) Importance: Undecided Status: New ** Changed in: corosync (Ubuntu Focal) Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned) ** Changed in: corosync (Ubuntu Disco) Status: New => Won't Fix ** Changed in: corosync (Ubuntu Trusty) Status: New => Won't Fix ** Changed in: corosync (Ubuntu Eoan) Status: New => Triaged ** Changed in: corosync (Ubuntu Xenial) Status: New => Triaged ** Changed in: corosync (Ubuntu Bionic) Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to corosync in Ubuntu. https://bugs.launchpad.net/bugs/1437359 Title: A PIDFILE is double-defined for the corosync-notifyd init script Status in corosync package in Ubuntu: In Progress Status in corosync source package in Trusty: Won't Fix Status in corosync source package in Xenial: Triaged Status in corosync source package in Bionic: Triaged Status in corosync source package in Disco: Won't Fix Status in corosync source package in Eoan: Triaged Status in corosync source package in Focal: In Progress Bug description: A /etc/init.d/corosync-notifyd contains two definitions for the PIDFILE: > PIDFILE=/var/run/$NAME.pid > SCRIPTNAME=/etc/init.d/$NAME > PIDFILE=/var/run/corosync.pid The first one is correct and the second one is wrong as it refers to the corosync service's pidfile instead The corosync package version is 2.3.3-1ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1437359/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1586876] Re: Corosync report "Started" itself too early
>From upstream documentation:
"""
Pacemaker used to obtain membership and quorum from a custom Corosync plugin.
This plugin also had the capability to start Pacemaker automatically when
Corosync was started. Neither behavior is possible with Corosync 2.0 and beyond
as support for plugins was removed.
Instead, Pacemaker must be started as a separate job/initscript. Also, since
Pacemaker made use of the plugin for message routing, a node using the plugin
(Corosync prior to 2.0) cannot talk to one that isn’t (Corosync 2.0+).
Rolling upgrades between these versions are therefore not possible and an
alternate strategy must be used.
"""
showing that since Ubuntu Trusty this detection behavior is not
supported any longer. Nowadays, we start both services separately and
using systemd.
Corosync starts with a simple one-node only (localhost) ring configured:
(c)rafaeldtinoco@clusterdev:~$ systemctl status corosync
● corosync.service - Corosync Cluster Engine
Loaded: loaded (/lib/systemd/system/corosync.service; enabled; vendor
preset: enabled)
Active: active (running) since Thu 2020-03-19 20:16:49 UTC; 45min ago
Docs: man:corosync
man:corosync.conf
man:corosync_overview
Main PID: 851 (corosync)
Tasks: 9 (limit: 23186)
Memory: 125.9M
CGroup: /system.slice/corosync.service
└─851 /usr/sbin/corosync -f
(c)rafaeldtinoco@clusterdev:~$ sudo corosync-quorumtool
Quorum information
--
Date: Thu Mar 19 21:02:21 2020
Quorum provider: corosync_votequorum
Nodes:1
Node ID: 1
Ring ID: 1.5
Quorate: Yes
Votequorum information
--
Expected votes: 1
Highest expected: 1
Total votes: 1
Quorum: 1
Flags:Quorate
Membership information
--
Nodeid Votes Name
1 1 node1 (local)
AND systemd is responsible to guarantee the synchronicity needed.
>From pacemaker service unit:
...
After=corosync.service
Requires=corosync.service
...
# If you want Corosync to stop whenever Pacemaker is stopped,
# uncomment the next line too:
#
# ExecStopPost=/bin/sh -c 'pidof pacemaker-controld || killall -TERM corosync'
...
# Pacemaker will restart along with Corosync if Corosync is stopped while
# Pacemaker is running.
# In this case, if you want to be fenced always (if you do not want to restart)
# uncomment ExecStopPost below.
#
# ExecStopPost=/bin/sh -c 'pidof corosync || \
# /usr/bin/systemctl --no-block stop pacemaker'
you have different options to control behavior for start/stop and
restart accordingly with corosync status.
** Changed in: corosync (Ubuntu Focal)
Status: Triaged => Fix Released
** Changed in: corosync (Ubuntu Eoan)
Status: Triaged => Fix Released
** Changed in: corosync (Ubuntu Bionic)
Status: Triaged => Fix Released
** Changed in: corosync (Ubuntu Xenial)
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed to corosync in Ubuntu.
https://bugs.launchpad.net/bugs/1586876
Title:
Corosync report "Started" itself too early
Status in corosync package in Ubuntu:
Fix Released
Status in corosync source package in Trusty:
Won't Fix
Status in corosync source package in Xenial:
Won't Fix
Status in corosync source package in Bionic:
Fix Released
Status in corosync source package in Disco:
Won't Fix
Status in corosync source package in Eoan:
Fix Released
Status in corosync source package in Focal:
Fix Released
Bug description:
Problem description:
currently, we have no service state check after start-stop-daemon in
do_start(),
it might lead to an error if corosync report itself started too early,
pacemaker might think it is a 'heartbeat' backended, which is not we desired,
we should check if corosync is "really" started, then report its state,
syslog with wrong state:
May 24 19:53:50 myhost corosync[1018]: [MAIN ] Corosync Cluster Engine
('1.4.2'): started and ready to provide service.
May 24 19:53:50 myhost corosync[1018]: [MAIN ] Corosync built-in features:
nss
May 24 19:53:50 myhost corosync[1018]: [MAIN ] Successfully read main
configuration file '/etc/corosync/corosync.conf'.
May 24 19:53:50 myhost corosync[1018]: [TOTEM ] Initializing transport
(UDP/IP Unicast).
May 24 19:53:50 myhost corosync[1018]: [TOTEM ] Initializing
transmit/receive security: libtomcrypt SOBER128/SHA1HMAC (mode 0).
May 24 19:53:50 myhost pacemakerd: [1094]: info: Invoked: pacemakerd
May 24 19:53:50 myhost pacemakerd: [1094]: info: crm_log_init_worker: Changed
active directory to /var/lib/heartbeat/cores/root
May 24 19:53:50 myhost pacemakerd: [1094]: info: get_cluster_type: Assuming a
'heartbeat' based cluster
May 24 19:53:50 myhost pacemakerd: [1094]: info: read_config: Reading
configure for stack:
[Ubuntu-ha] [Bug 1239734] Re: corosync sends first time users on a hunt, simple fix
Currently corosync is started by default with a single node ring formed
with localhost:
(c)rafaeldtinoco@clusterdev:~/.../sources/ubuntu/corosync$ systemctl status
corosync
● corosync.service - Corosync Cluster Engine
Loaded: loaded (/lib/systemd/system/corosync.service; enabled; vendor
preset: enabled)
Active: active (running) since Thu 2020-03-19 20:16:49 UTC; 2min 10s ago
Docs: man:corosync
man:corosync.conf
man:corosync_overview
Main PID: 851 (corosync)
Tasks: 9 (limit: 23186)
Memory: 125.7M
CGroup: /system.slice/corosync.service
└─851 /usr/sbin/corosync -f
(c)rafaeldtinoco@clusterdev:~/.../sources/ubuntu/corosync$ sudo
corosync-quorumtool
Quorum information
--
Date: Thu Mar 19 20:19:37 2020
Quorum provider: corosync_votequorum
Nodes:1
Node ID: 1
Ring ID: 1.5
Quorate: Yes
Votequorum information
--
Expected votes: 1
Highest expected: 1
Total votes: 1
Quorum: 1
Flags:Quorate
Membership information
--
Nodeid Votes Name
1 1 node1 (local)
Because we try to make things "easier" (no failure on startups because
the lack of configuration files, for example). Of course having a HA
cluster is something beyond the scope of this bug and it might require
an experienced system administrator to be able to make corosync to work
in a meaningful way.
Nevertheless, for any future bug readers, may I recommend the following
reading:
https://discourse.ubuntu.com/t/ubuntu-high-availability-shared-scsi-
disk-environments/14874
in order to get a simple, yet supported, cluster configuration in a
shared scsi environment.
Thanks for reporting this.
** Changed in: corosync (Ubuntu)
Status: Triaged => Fix Released
** Changed in: corosync (Ubuntu)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed to corosync in Ubuntu.
https://bugs.launchpad.net/bugs/1239734
Title:
corosync sends first time users on a hunt, simple fix
Status in corosync package in Ubuntu:
Fix Released
Bug description:
Corosync's init script properly fails to start by default to protect
us. I get that, but the wild goose chase that a new user ends up on is
a UX bug and in at least one case, I saw a user who simply changed
distros because he couldn't figure it out claiming Ubuntu wasn't ready
for business. (Yeah, I know that's nonsense but his complaint on
spiceworks forums is among the top links on google for 'ubuntu
corosync'. )
The puppet daemon does the same thing, but it has a bit of logic that
when someone tries to start it and this file overrides them, it simply
tells the user and tells them where to change the variable.
Here is the code they use in their init.
start_puppet_agent() {
if is_true "$START" ; then
start-stop-daemon --start --quiet --pidfile $PIDFILE \
--startas $DAEMON -- $NAME $DAEMON_OPTS
else
echo ""
echo "puppet not configured to start, please edit /etc/default/puppet
to enable"
fi
}
Here is the equivalent code in corosync's init.
do_start()
{
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
start-stop-daemon --start --quiet --exec $DAEMON --test > /dev/null \
|| return 1
start-stop-daemon --start --quiet --exec $DAEMON -- $DAEMON_ARGS \
|| return 2
# Add code here, if necessary, that waits for the process to be ready
# to handle requests from services started subsequently which depend
# on this one. As a last resort, sleep for some time.
pidof corosync > $PIDFILE
}
I won't bother combining it as I find each item I try that the devs
usually find my solution rather overly complicated. I'm sure you can
handle it better than I.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1239734/+subscriptions
___
Mailing list: https://launchpad.net/~ubuntu-ha
Post to : ubuntu-ha@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-ha
More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1586876] Re: Corosync report "Started" itself too early
** Also affects: corosync (Ubuntu Eoan)
Importance: Undecided
Status: New
** Also affects: corosync (Ubuntu Disco)
Importance: Undecided
Status: New
** Also affects: corosync (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: corosync (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: corosync (Ubuntu Trusty)
Importance: Undecided
Status: New
** Also affects: corosync (Ubuntu Focal)
Importance: Medium
Assignee: guessi (guessi)
Status: In Progress
** Changed in: corosync (Ubuntu Focal)
Assignee: guessi (guessi) => (unassigned)
** Changed in: corosync (Ubuntu Focal)
Importance: Medium => Undecided
** Changed in: corosync (Ubuntu Trusty)
Status: New => Won't Fix
** Changed in: corosync (Ubuntu Disco)
Status: New => Won't Fix
** Changed in: corosync (Ubuntu Focal)
Status: In Progress => Triaged
** Changed in: corosync (Ubuntu Eoan)
Status: New => Triaged
** Changed in: corosync (Ubuntu Xenial)
Status: New => Triaged
** Changed in: corosync (Ubuntu Bionic)
Status: New => Triaged
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed to corosync in Ubuntu.
https://bugs.launchpad.net/bugs/1586876
Title:
Corosync report "Started" itself too early
Status in corosync package in Ubuntu:
Triaged
Status in corosync source package in Trusty:
Won't Fix
Status in corosync source package in Xenial:
Triaged
Status in corosync source package in Bionic:
Triaged
Status in corosync source package in Disco:
Won't Fix
Status in corosync source package in Eoan:
Triaged
Status in corosync source package in Focal:
Triaged
Bug description:
Problem description:
currently, we have no service state check after start-stop-daemon in
do_start(),
it might lead to an error if corosync report itself started too early,
pacemaker might think it is a 'heartbeat' backended, which is not we desired,
we should check if corosync is "really" started, then report its state,
syslog with wrong state:
May 24 19:53:50 myhost corosync[1018]: [MAIN ] Corosync Cluster Engine
('1.4.2'): started and ready to provide service.
May 24 19:53:50 myhost corosync[1018]: [MAIN ] Corosync built-in features:
nss
May 24 19:53:50 myhost corosync[1018]: [MAIN ] Successfully read main
configuration file '/etc/corosync/corosync.conf'.
May 24 19:53:50 myhost corosync[1018]: [TOTEM ] Initializing transport
(UDP/IP Unicast).
May 24 19:53:50 myhost corosync[1018]: [TOTEM ] Initializing
transmit/receive security: libtomcrypt SOBER128/SHA1HMAC (mode 0).
May 24 19:53:50 myhost pacemakerd: [1094]: info: Invoked: pacemakerd
May 24 19:53:50 myhost pacemakerd: [1094]: info: crm_log_init_worker: Changed
active directory to /var/lib/heartbeat/cores/root
May 24 19:53:50 myhost pacemakerd: [1094]: info: get_cluster_type: Assuming a
'heartbeat' based cluster
May 24 19:53:50 myhost pacemakerd: [1094]: info: read_config: Reading
configure for stack: heartbeat
expected result:
May 24 21:45:02 myhost corosync[1021]: [MAIN ] Completed service
synchronization, ready to provide service.
May 24 21:45:02 myhost pacemakerd: [1106]: info: Invoked: pacemakerd
May 24 21:45:02 myhost pacemakerd: [1106]: info: crm_log_init_worker: Changed
active directory to /var/lib/heartbeat/cores/root
May 24 21:45:02 myhost pacemakerd: [1106]: info: config_find_next: Processing
additional service options...
May 24 21:45:02 myhost pacemakerd: [1106]: info: get_config_opt: Found
'pacemaker' for option: name
May 24 21:45:02 myhost pacemakerd: [1106]: info: get_config_opt: Found '1'
for option: ver
May 24 21:45:02 myhost pacemakerd: [1106]: info: get_cluster_type: Detected
an active 'classic openais (with plugin)' cluster
please note the order of following two lines:
* corosync: [MAIN ] Completed service synchronization, ready to provide
service.
* pacemakerd: info: get_cluster_type: ...
affected versions:
ALL (precise, trusty, vivid, wily, xenial, yakkety)
upstream solution: wait_for_ipc()
https://github.com/corosync/corosync/blob/master/init/corosync.in#L84-L99
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1586876/+subscriptions
___
Mailing list: https://launchpad.net/~ubuntu-ha
Post to : ubuntu-ha@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-ha
More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1019833] Re: problem wtih the configuration of the cluster.conf file. when
** Also affects: corosync (Ubuntu Trusty) Importance: Undecided Status: New ** Changed in: corosync (Ubuntu Trusty) Status: New => Incomplete ** Changed in: corosync (Ubuntu) Status: Incomplete => Fix Released ** Changed in: corosync (Ubuntu) Assignee: Joao (nobrefr) => (unassigned) ** Changed in: corosync (Ubuntu) Importance: Medium => Undecided ** Changed in: corosync (Ubuntu) Status: Fix Released => Invalid -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to corosync in Ubuntu. https://bugs.launchpad.net/bugs/1019833 Title: problem wtih the configuration of the cluster.conf file. when Status in corosync package in Ubuntu: Invalid Status in corosync source package in Trusty: Incomplete Bug description: Hello, I'm trying to install and configure a small corosync cluster with two nodes, on OS Ubuntu 12.04 LTS. There is a problem wtih the configuration of the cluster.conf file. when I try to validate it I get the error message: extra element rm in interleave. command used to validate: ccs_config_validate. Both nodes are working. - Used command clustat and cman_tool nodes I send a copy of cluster.conf files of both nodes. Corosync version: 1.4.2 Thanks in advance, João Francisco To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1019833/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 637127] Re: TTL is one - prevents multicast routing
Correct flag for this bug is: Fix Released per upstream fix: commit d3b983953d43dd17162be04de405d223fb21cd26 Author: Angus Salkeld Date: Wed Nov 24 14:35:56 2010 +1100 Add totem/interface/ttl config option. This adds a per-interface config option to adjust the TTL. Signed-off-by: Angus Salkeld Reviewed-by: Steven Dake ** Changed in: corosync (Ubuntu) Status: Incomplete => Fix Released -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to corosync in Ubuntu. https://bugs.launchpad.net/bugs/637127 Title: TTL is one - prevents multicast routing Status in corosync package in Ubuntu: Fix Released Status in corosync package in Fedora: Won't Fix Bug description: Binary package hint: corosync corosync uses a TTL of 1 in its multicast packets - restricting its use to a local segment and making it unusable in a multicast routed environment (such as with routed virtual machines). ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: corosync 1.2.0-0ubuntu1 ProcVersionSignature: Ubuntu 2.6.32-22.36-generic 2.6.32.11+drm33.2 Uname: Linux 2.6.32-22-generic i686 Architecture: i386 Date: Mon Sep 13 13:17:59 2010 ProcEnviron: PATH=(custom, no user) LANG=en_GB SHELL=/bin/bash SourcePackage: corosync To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/637127/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1251298] Re: Failed to sign on to LRMd with Heartbeat/Pacemaker
Thank you for taking the time to report this bug. In an effort to keep an up-to-date and valid list of bugs to work on, I have reviewed this report to verify it still requires effort and occurs on an Ubuntu release in standard support, and it does not. Judging by the existing comments, and the pointed upstream discussion thread, it appears that the wrong lrmd was being set after upgrade and that led existing cluster to confusion when connecting to the local resource manager daemon. It is unfortunate that we were unable to resolve this defect, however there appears to be no further action possible at this time. I am therefore moving the bug to 'Incomplete'. If you disagree or have new information, we would be grateful if you could please add a comment stating why and then change the status of the bug to 'New'. ** Changed in: cluster-glue (Ubuntu) Status: Confirmed => Incomplete ** Also affects: cluster-glue (Ubuntu Trusty) Importance: Undecided Status: New ** Changed in: cluster-glue (Ubuntu Trusty) Status: New => Incomplete ** Changed in: cluster-glue (Ubuntu) Status: Incomplete => Fix Released ** Changed in: cluster-glue (Ubuntu) Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned) -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to cluster-glue in Ubuntu. https://bugs.launchpad.net/bugs/1251298 Title: Failed to sign on to LRMd with Heartbeat/Pacemaker Status in cluster-glue package in Ubuntu: Fix Released Status in cluster-glue source package in Trusty: Incomplete Bug description: I'm running a 2 node heartbeat/pacemaker cluster, which was working fine with Ubuntu 13.04 After upgrading from Ubuntu 13.04 to Ubuntu 13.10, Heartbeat/Pacemaker keeps restarting the system due to sign on errors of lrmd and heartbeat tries to recover. As one system is already on ubuntu 13.10 and one system still running 13.04, I've tried it without the second node, which leads to the same behavior, which occurs before any cluster communication happens. Syslog: Nov 14 15:53:06 wolverine crmd[2464]: warning: do_lrm_control: Failed to sign on to the LRM 1 (30 max) times Nov 14 15:53:06 wolverine crmd[2464]: notice: crmd_client_status_callback: Status update: Client wolverine.domain.tld/crmd now has status [join] (DC=false) Nov 14 15:53:06 wolverine crmd[2464]: notice: crmd_client_status_callback: Status update: Client wolverine.domain.tld/crmd now has status [online] (DC=false) Nov 14 15:53:06 wolverine crmd[2464]: warning: do_lrm_control: Failed to sign on to the LRM 2 (30 max) times Nov 14 15:53:06 wolverine crmd[2464]: warning: do_lrm_control: Failed to sign on to the LRM 3 (30 max) times Nov 14 15:53:07 wolverine stonith-ng[2462]: notice: setup_cib: Watching for stonith topology changes Nov 14 15:53:07 wolverine stonith-ng[2462]: notice: unpack_config: On loss of CCM Quorum: Ignore Nov 14 15:53:08 wolverine crmd[2464]: warning: do_lrm_control: Failed to sign on to the LRM 4 (30 max) times Nov 14 15:53:10 wolverine crmd[2464]: warning: do_lrm_control: Failed to sign on to the LRM 5 (30 max) times Nov 14 15:53:12 wolverine crmd[2464]: warning: do_lrm_control: Failed to sign on to the LRM 6 (30 max) times Nov 14 15:53:14 wolverine crmd[2464]: warning: do_lrm_control: Failed to sign on to the LRM 7 (30 max) times Nov 14 15:53:16 wolverine crmd[2464]: warning: do_lrm_control: Failed to sign on to the LRM 8 (30 max) times Nov 14 15:53:18 wolverine crmd[2464]: warning: do_lrm_control: Failed to sign on to the LRM 9 (30 max) times Nov 14 15:53:20 wolverine crmd[2464]: warning: do_lrm_control: Failed to sign on to the LRM 10 (30 max) times Nov 14 15:53:22 wolverine crmd[2464]: warning: do_lrm_control: Failed to sign on to the LRM 11 (30 max) times Nov 14 15:53:24 wolverine crmd[2464]: warning: do_lrm_control: Failed to sign on to the LRM 12 (30 max) times Nov 14 15:53:26 wolverine crmd[2464]: warning: do_lrm_control: Failed to sign on to the LRM 13 (30 max) times Nov 14 15:53:28 wolverine crmd[2464]: warning: do_lrm_control: Failed to sign on to the LRM 14 (30 max) times Nov 14 15:53:30 wolverine crmd[2464]: warning: do_lrm_control: Failed to sign on to the LRM 15 (30 max) times Nov 14 15:53:32 wolverine crmd[2464]: warning: do_lrm_control: Failed to sign on to the LRM 16 (30 max) times Nov 14 15:53:34 wolverine crmd[2464]: warning: do_lrm_control: Failed to sign on to the LRM 17 (30 max) times Nov 14 15:53:36 wolverine crmd[2464]: warning: do_lrm_control: Failed to sign on to the LRM 18 (30 max) times Nov 14 15:53:38 wolverine crmd[2464]: warning: do_lrm_control: Failed to sign on to the LRM 19 (30 max) times Nov 14 15:53:40 wolverine crmd[2464]: warning: do_lrm_control: Failed to sign on to the LRM 20 (30 max) times Nov 14 15:53:42 wolverine crmd[2464]: warning: do_lrm_con
[Ubuntu-ha] [Bug 1866119] Re: [bionic] fence_scsi not working properly with Pacemaker 1.1.18-2ubuntu1.1
** Merge proposal unlinked: https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/pacemaker/+git/pacemaker/+merge/380336 -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1866119 Title: [bionic] fence_scsi not working properly with Pacemaker 1.1.18-2ubuntu1.1 Status in pacemaker package in Ubuntu: Fix Released Status in pacemaker source package in Bionic: In Progress Bug description: OBS: This bug was originally into LP: #1865523 but it was split. SRU: pacemaker [Impact] * fence_scsi is not currently working in a share disk environment * all clusters relying in fence_scsi and/or fence_scsi + watchdog won't be able to start the fencing agents OR, in worst case scenarios, the fence_scsi agent might start but won't make scsi reservations in the shared scsi disk. * this bug is taking care of pacemaker 1.1.18 issues with fence_scsi, since the later was fixed at LP: #1865523. [Test Case] * having a 3-node setup, nodes called "clubionic01, clubionic02, clubionic03", with a shared scsi disk (fully supporting persistent reservations) /dev/sda, with corosync and pacemaker operational and running, one might try: rafaeldtinoco@clubionic01:~$ crm configure crm(live)configure# property stonith-enabled=on crm(live)configure# property stonith-action=off crm(live)configure# property no-quorum-policy=stop crm(live)configure# property have-watchdog=true crm(live)configure# commit crm(live)configure# end crm(live)# end rafaeldtinoco@clubionic01:~$ crm configure primitive fence_clubionic \ stonith:fence_scsi params \ pcmk_host_list="clubionic01 clubionic02 clubionic03" \ devices="/dev/sda" \ meta provides=unfencing And see the following errors: Failed Actions: * fence_clubionic_start_0 on clubionic02 'unknown error' (1): call=6, status=Error, exitreason='', last-rc-change='Wed Mar 4 19:53:12 2020', queued=0ms, exec=1105ms * fence_clubionic_start_0 on clubionic03 'unknown error' (1): call=6, status=Error, exitreason='', last-rc-change='Wed Mar 4 19:53:13 2020', queued=0ms, exec=1109ms * fence_clubionic_start_0 on clubionic01 'unknown error' (1): call=6, status=Error, exitreason='', last-rc-change='Wed Mar 4 19:53:11 2020', queued=0ms, exec=1108ms and corosync.log will show: warning: unpack_rsc_op_failure: Processing failed op start for fence_clubionic on clubionic01: unknown error (1) [Regression Potential] * LP: #1865523 shows fence_scsi fully operational after SRU for that bug is done. * LP: #1865523 used pacemaker 1.1.19 (vanilla) in order to fix fence_scsi. * There are changes to: cluster resource manager daemon, local resource manager daemon and police engine. From all the changes, the police engine fix is the biggest, but still not big for a SRU. This could cause police engine, thus cluster decisions, to mal function. * All patches are based in upstream fixes made right after Pacemaker-1.1.18, used by Ubuntu Bionic and were tested with fence_scsi to make sure it fixed the issues. [Other Info] * Original Description: Trying to setup a cluster with an iscsi shared disk, using fence_scsi as the fencing mechanism, I realized that fence_scsi is not working in Ubuntu Bionic. I first thought it was related to Azure environment (LP: #1864419), where I was trying this environment, but then, trying locally, I figured out that somehow pacemaker 1.1.18 is not fencing the shared scsi disk properly. Note: I was able to "backport" vanilla 1.1.19 from upstream and fence_scsi worked. I have then tried 1.1.18 without all quilt patches and it didnt work as well. I think that bisecting 1.1.18 <-> 1.1.19 might tell us which commit has fixed the behaviour needed by the fence_scsi agent. (k)rafaeldtinoco@clubionic01:~$ crm conf show node 1: clubionic01.private node 2: clubionic02.private node 3: clubionic03.private primitive fence_clubionic stonith:fence_scsi \ params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ meta provides=unfencing property cib-bootstrap-options: \ have-watchdog=false \ dc-version=1.1.18-2b07d5c5a9 \ cluster-infrastructure=corosync \ cluster-name=clubionic \ stonith-enabled=on \ stonith-action=off \ no-quorum-policy=stop \ symmetric-cluster=true (k)rafaeldtinoco@clubionic02:~$ sudo crm_mon -1 Stack: corosync Current DC: clubionic01.private (version 1.1.18-2b07d5c5a9) - partition with quorum Last updated: Mon Mar 2 15:55:30 2020 Last change: Mon Mar 2 15:45:33 2020 by root via cibadmin on clubionic01.private 3 nodes configured 1 resource configured Online: [ clubionic01.private clubionic02.private clubionic03.private ]
[Ubuntu-ha] [Bug 1866119] Re: [bionic] fence_scsi not working properly with Pacemaker 1.1.18-2ubuntu1.1
** Description changed: OBS: This bug was originally into LP: #1865523 but it was split. SRU: pacemaker [Impact] - * fence_scsi is not currently working in a share disk environment + * fence_scsi is not currently working in a share disk environment - * all clusters relying in fence_scsi and/or fence_scsi + watchdog won't + * all clusters relying in fence_scsi and/or fence_scsi + watchdog won't be able to start the fencing agents OR, in worst case scenarios, the fence_scsi agent might start but won't make scsi reservations in the shared scsi disk. - * this bug is taking care of pacemaker 1.1.18 issues with fence_scsi, + * this bug is taking care of pacemaker 1.1.18 issues with fence_scsi, since the later was fixed at LP: #1865523. [Test Case] - * having a 3-node setup, nodes called "clubionic01, clubionic02, + * having a 3-node setup, nodes called "clubionic01, clubionic02, clubionic03", with a shared scsi disk (fully supporting persistent reservations) /dev/sda, with corosync and pacemaker operational and running, one might try: rafaeldtinoco@clubionic01:~$ crm configure crm(live)configure# property stonith-enabled=on crm(live)configure# property stonith-action=off crm(live)configure# property no-quorum-policy=stop crm(live)configure# property have-watchdog=true crm(live)configure# commit crm(live)configure# end crm(live)# end rafaeldtinoco@clubionic01:~$ crm configure primitive fence_clubionic \ - stonith:fence_scsi params \ - pcmk_host_list="clubionic01 clubionic02 clubionic03" \ - devices="/dev/sda" \ - meta provides=unfencing + stonith:fence_scsi params \ + pcmk_host_list="clubionic01 clubionic02 clubionic03" \ + devices="/dev/sda" \ + meta provides=unfencing And see the following errors: Failed Actions: * fence_clubionic_start_0 on clubionic02 'unknown error' (1): call=6, status=Error, exitreason='', - last-rc-change='Wed Mar 4 19:53:12 2020', queued=0ms, exec=1105ms + last-rc-change='Wed Mar 4 19:53:12 2020', queued=0ms, exec=1105ms * fence_clubionic_start_0 on clubionic03 'unknown error' (1): call=6, status=Error, exitreason='', - last-rc-change='Wed Mar 4 19:53:13 2020', queued=0ms, exec=1109ms + last-rc-change='Wed Mar 4 19:53:13 2020', queued=0ms, exec=1109ms * fence_clubionic_start_0 on clubionic01 'unknown error' (1): call=6, status=Error, exitreason='', - last-rc-change='Wed Mar 4 19:53:11 2020', queued=0ms, exec=1108ms + last-rc-change='Wed Mar 4 19:53:11 2020', queued=0ms, exec=1108ms and corosync.log will show: warning: unpack_rsc_op_failure: Processing failed op start for fence_clubionic on clubionic01: unknown error (1) [Regression Potential] - * LP: #1865523 shows fence_scsi fully operational after SRU for that + * LP: #1865523 shows fence_scsi fully operational after SRU for that bug is done. - * LP: #1865523 used pacemaker 1.1.19 (vanilla) in order to fix + * LP: #1865523 used pacemaker 1.1.19 (vanilla) in order to fix fence_scsi. - * TODO + * There are changes to: cluster resource manager daemon, local resource + manager daemon and police engine. From all the changes, the police + engine fix is the biggest, but still not big for a SRU. This could cause + police engine, thus cluster decisions, to mal function. + + * All patches are based in upstream fixes made right after + Pacemaker-1.1.18, used by Ubuntu Bionic and were tested with fence_scsi + to make sure it fixed the issues. [Other Info] - * Original Description: + * Original Description: Trying to setup a cluster with an iscsi shared disk, using fence_scsi as the fencing mechanism, I realized that fence_scsi is not working in Ubuntu Bionic. I first thought it was related to Azure environment (LP: #1864419), where I was trying this environment, but then, trying locally, I figured out that somehow pacemaker 1.1.18 is not fencing the shared scsi disk properly. Note: I was able to "backport" vanilla 1.1.19 from upstream and fence_scsi worked. I have then tried 1.1.18 without all quilt patches and it didnt work as well. I think that bisecting 1.1.18 <-> 1.1.19 might tell us which commit has fixed the behaviour needed by the fence_scsi agent. (k)rafaeldtinoco@clubionic01:~$ crm conf show node 1: clubionic01.private node 2: clubionic02.private node 3: clubionic03.private primitive fence_clubionic stonith:fence_scsi \ params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ meta provides=unfencing property cib-bootstrap-options: \ have-watchdog=false \ dc-version=1.1.18-2b07d5c5a9 \ cluster-infrastructure=corosync \ cluster-name=clubionic \ stonith-enabled=on \ stonith-action=off \ no-quorum-policy=stop \ symmetric-cluster=true
[Ubuntu-ha] [Bug 1866119] Re: [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1
SUMMARY: One using packages from: https://launchpad.net/~ubuntu-server-ha/+archive/ubuntu/staging in Ubuntu Bionic will be workedaround temporarily (until fixes are released) for the bugs: https://bugs.launchpad.net/ubuntu/+source/fence-agents/+bug/1865523 https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1866119 -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1866119 Title: [bionic] fence_scsi not working properly with Pacemaker 1.1.18-2ubuntu1.1 Status in pacemaker package in Ubuntu: Fix Released Status in pacemaker source package in Bionic: In Progress Bug description: OBS: This bug was originally into LP: #1865523 but it was split. SRU: pacemaker [Impact] * fence_scsi is not currently working in a share disk environment * all clusters relying in fence_scsi and/or fence_scsi + watchdog won't be able to start the fencing agents OR, in worst case scenarios, the fence_scsi agent might start but won't make scsi reservations in the shared scsi disk. * this bug is taking care of pacemaker 1.1.18 issues with fence_scsi, since the later was fixed at LP: #1865523. [Test Case] * having a 3-node setup, nodes called "clubionic01, clubionic02, clubionic03", with a shared scsi disk (fully supporting persistent reservations) /dev/sda, with corosync and pacemaker operational and running, one might try: rafaeldtinoco@clubionic01:~$ crm configure crm(live)configure# property stonith-enabled=on crm(live)configure# property stonith-action=off crm(live)configure# property no-quorum-policy=stop crm(live)configure# property have-watchdog=true crm(live)configure# commit crm(live)configure# end crm(live)# end rafaeldtinoco@clubionic01:~$ crm configure primitive fence_clubionic \ stonith:fence_scsi params \ pcmk_host_list="clubionic01 clubionic02 clubionic03" \ devices="/dev/sda" \ meta provides=unfencing And see the following errors: Failed Actions: * fence_clubionic_start_0 on clubionic02 'unknown error' (1): call=6, status=Error, exitreason='', last-rc-change='Wed Mar 4 19:53:12 2020', queued=0ms, exec=1105ms * fence_clubionic_start_0 on clubionic03 'unknown error' (1): call=6, status=Error, exitreason='', last-rc-change='Wed Mar 4 19:53:13 2020', queued=0ms, exec=1109ms * fence_clubionic_start_0 on clubionic01 'unknown error' (1): call=6, status=Error, exitreason='', last-rc-change='Wed Mar 4 19:53:11 2020', queued=0ms, exec=1108ms and corosync.log will show: warning: unpack_rsc_op_failure: Processing failed op start for fence_clubionic on clubionic01: unknown error (1) [Regression Potential] * LP: #1865523 shows fence_scsi fully operational after SRU for that bug is done. * LP: #1865523 used pacemaker 1.1.19 (vanilla) in order to fix fence_scsi. * TODO [Other Info] * Original Description: Trying to setup a cluster with an iscsi shared disk, using fence_scsi as the fencing mechanism, I realized that fence_scsi is not working in Ubuntu Bionic. I first thought it was related to Azure environment (LP: #1864419), where I was trying this environment, but then, trying locally, I figured out that somehow pacemaker 1.1.18 is not fencing the shared scsi disk properly. Note: I was able to "backport" vanilla 1.1.19 from upstream and fence_scsi worked. I have then tried 1.1.18 without all quilt patches and it didnt work as well. I think that bisecting 1.1.18 <-> 1.1.19 might tell us which commit has fixed the behaviour needed by the fence_scsi agent. (k)rafaeldtinoco@clubionic01:~$ crm conf show node 1: clubionic01.private node 2: clubionic02.private node 3: clubionic03.private primitive fence_clubionic stonith:fence_scsi \ params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ meta provides=unfencing property cib-bootstrap-options: \ have-watchdog=false \ dc-version=1.1.18-2b07d5c5a9 \ cluster-infrastructure=corosync \ cluster-name=clubionic \ stonith-enabled=on \ stonith-action=off \ no-quorum-policy=stop \ symmetric-cluster=true (k)rafaeldtinoco@clubionic02:~$ sudo crm_mon -1 Stack: corosync Current DC: clubionic01.private (version 1.1.18-2b07d5c5a9) - partition with quorum Last updated: Mon Mar 2 15:55:30 2020 Last change: Mon Mar 2 15:45:33 2020 by root via cibadmin on clubionic01.private 3 nodes configured 1 resource configured Online: [ clubionic01.private clubionic02.private clubionic03.private ] Active resources: fence_clubionic (stonith:fence_scsi): Started clubionic01.private (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist --in --read-keys --device=/dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device
[Ubuntu-ha] [Bug 1866119] Re: [bionic] fence_scsi not working properly with Pacemaker 1.1.18-2ubuntu1.1
** Summary changed: - [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1 + [bionic] fence_scsi not working properly with Pacemaker 1.1.18-2ubuntu1.1 -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1866119 Title: [bionic] fence_scsi not working properly with Pacemaker 1.1.18-2ubuntu1.1 Status in pacemaker package in Ubuntu: Fix Released Status in pacemaker source package in Bionic: In Progress Bug description: OBS: This bug was originally into LP: #1865523 but it was split. SRU: pacemaker [Impact] * fence_scsi is not currently working in a share disk environment * all clusters relying in fence_scsi and/or fence_scsi + watchdog won't be able to start the fencing agents OR, in worst case scenarios, the fence_scsi agent might start but won't make scsi reservations in the shared scsi disk. * this bug is taking care of pacemaker 1.1.18 issues with fence_scsi, since the later was fixed at LP: #1865523. [Test Case] * having a 3-node setup, nodes called "clubionic01, clubionic02, clubionic03", with a shared scsi disk (fully supporting persistent reservations) /dev/sda, with corosync and pacemaker operational and running, one might try: rafaeldtinoco@clubionic01:~$ crm configure crm(live)configure# property stonith-enabled=on crm(live)configure# property stonith-action=off crm(live)configure# property no-quorum-policy=stop crm(live)configure# property have-watchdog=true crm(live)configure# commit crm(live)configure# end crm(live)# end rafaeldtinoco@clubionic01:~$ crm configure primitive fence_clubionic \ stonith:fence_scsi params \ pcmk_host_list="clubionic01 clubionic02 clubionic03" \ devices="/dev/sda" \ meta provides=unfencing And see the following errors: Failed Actions: * fence_clubionic_start_0 on clubionic02 'unknown error' (1): call=6, status=Error, exitreason='', last-rc-change='Wed Mar 4 19:53:12 2020', queued=0ms, exec=1105ms * fence_clubionic_start_0 on clubionic03 'unknown error' (1): call=6, status=Error, exitreason='', last-rc-change='Wed Mar 4 19:53:13 2020', queued=0ms, exec=1109ms * fence_clubionic_start_0 on clubionic01 'unknown error' (1): call=6, status=Error, exitreason='', last-rc-change='Wed Mar 4 19:53:11 2020', queued=0ms, exec=1108ms and corosync.log will show: warning: unpack_rsc_op_failure: Processing failed op start for fence_clubionic on clubionic01: unknown error (1) [Regression Potential] * LP: #1865523 shows fence_scsi fully operational after SRU for that bug is done. * LP: #1865523 used pacemaker 1.1.19 (vanilla) in order to fix fence_scsi. * TODO [Other Info] * Original Description: Trying to setup a cluster with an iscsi shared disk, using fence_scsi as the fencing mechanism, I realized that fence_scsi is not working in Ubuntu Bionic. I first thought it was related to Azure environment (LP: #1864419), where I was trying this environment, but then, trying locally, I figured out that somehow pacemaker 1.1.18 is not fencing the shared scsi disk properly. Note: I was able to "backport" vanilla 1.1.19 from upstream and fence_scsi worked. I have then tried 1.1.18 without all quilt patches and it didnt work as well. I think that bisecting 1.1.18 <-> 1.1.19 might tell us which commit has fixed the behaviour needed by the fence_scsi agent. (k)rafaeldtinoco@clubionic01:~$ crm conf show node 1: clubionic01.private node 2: clubionic02.private node 3: clubionic03.private primitive fence_clubionic stonith:fence_scsi \ params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ meta provides=unfencing property cib-bootstrap-options: \ have-watchdog=false \ dc-version=1.1.18-2b07d5c5a9 \ cluster-infrastructure=corosync \ cluster-name=clubionic \ stonith-enabled=on \ stonith-action=off \ no-quorum-policy=stop \ symmetric-cluster=true (k)rafaeldtinoco@clubionic02:~$ sudo crm_mon -1 Stack: corosync Current DC: clubionic01.private (version 1.1.18-2b07d5c5a9) - partition with quorum Last updated: Mon Mar 2 15:55:30 2020 Last change: Mon Mar 2 15:45:33 2020 by root via cibadmin on clubionic01.private 3 nodes configured 1 resource configured Online: [ clubionic01.private clubionic02.private clubionic03.private ] Active resources: fence_clubionic (stonith:fence_scsi): Started clubionic01.private (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist --in --read-keys --device=/dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x0, there are NO registered reservation keys (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist -r /dev/sda LIO-ORG
[Ubuntu-ha] [Bug 1866119] Re: [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1
** Description changed: + OBS: This bug was originally into LP: #1865523 but it was split. + + SRU: pacemaker + + [Impact] + + * fence_scsi is not currently working in a share disk environment + + * all clusters relying in fence_scsi and/or fence_scsi + watchdog won't + be able to start the fencing agents OR, in worst case scenarios, the + fence_scsi agent might start but won't make scsi reservations in the + shared scsi disk. + + * this bug is taking care of pacemaker 1.1.18 issues with fence_scsi, + since the later was fixed at LP: #1865523. + + [Test Case] + + * having a 3-node setup, nodes called "clubionic01, clubionic02, + clubionic03", with a shared scsi disk (fully supporting persistent + reservations) /dev/sda, with corosync and pacemaker operational and + running, one might try: + + rafaeldtinoco@clubionic01:~$ crm configure + crm(live)configure# property stonith-enabled=on + crm(live)configure# property stonith-action=off + crm(live)configure# property no-quorum-policy=stop + crm(live)configure# property have-watchdog=true + crm(live)configure# commit + crm(live)configure# end + crm(live)# end + + rafaeldtinoco@clubionic01:~$ crm configure primitive fence_clubionic \ + stonith:fence_scsi params \ + pcmk_host_list="clubionic01 clubionic02 clubionic03" \ + devices="/dev/sda" \ + meta provides=unfencing + + And see the following errors: + + Failed Actions: + * fence_clubionic_start_0 on clubionic02 'unknown error' (1): call=6, status=Error, exitreason='', + last-rc-change='Wed Mar 4 19:53:12 2020', queued=0ms, exec=1105ms + * fence_clubionic_start_0 on clubionic03 'unknown error' (1): call=6, status=Error, exitreason='', + last-rc-change='Wed Mar 4 19:53:13 2020', queued=0ms, exec=1109ms + * fence_clubionic_start_0 on clubionic01 'unknown error' (1): call=6, status=Error, exitreason='', + last-rc-change='Wed Mar 4 19:53:11 2020', queued=0ms, exec=1108ms + + and corosync.log will show: + + warning: unpack_rsc_op_failure: Processing failed op start for + fence_clubionic on clubionic01: unknown error (1) + + [Regression Potential] + + * LP: #1865523 shows fence_scsi fully operational after SRU for that + bug is done. + + * LP: #1865523 used pacemaker 1.1.19 (vanilla) in order to fix + fence_scsi. + + * TODO + + [Other Info] + + * Original Description: + Trying to setup a cluster with an iscsi shared disk, using fence_scsi as the fencing mechanism, I realized that fence_scsi is not working in Ubuntu Bionic. I first thought it was related to Azure environment (LP: #1864419), where I was trying this environment, but then, trying locally, I figured out that somehow pacemaker 1.1.18 is not fencing the shared scsi disk properly. Note: I was able to "backport" vanilla 1.1.19 from upstream and fence_scsi worked. I have then tried 1.1.18 without all quilt patches and it didnt work as well. I think that bisecting 1.1.18 <-> 1.1.19 might tell us which commit has fixed the behaviour needed by the fence_scsi agent. (k)rafaeldtinoco@clubionic01:~$ crm conf show node 1: clubionic01.private node 2: clubionic02.private node 3: clubionic03.private primitive fence_clubionic stonith:fence_scsi \ - params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ - meta provides=unfencing + params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ + meta provides=unfencing property cib-bootstrap-options: \ - have-watchdog=false \ - dc-version=1.1.18-2b07d5c5a9 \ - cluster-infrastructure=corosync \ - cluster-name=clubionic \ - stonith-enabled=on \ - stonith-action=off \ - no-quorum-policy=stop \ - symmetric-cluster=true + have-watchdog=false \ + dc-version=1.1.18-2b07d5c5a9 \ + cluster-infrastructure=corosync \ + cluster-name=clubionic \ + stonith-enabled=on \ + stonith-action=off \ + no-quorum-policy=stop \ + symmetric-cluster=true (k)rafaeldtinoco@clubionic02:~$ sudo crm_mon -1 Stack: corosync Current DC: clubionic01.private (version 1.1.18-2b07d5c5a9) - partition with quorum Last updated: Mon Mar 2 15:55:30 2020 Last change: Mon Mar 2 15:45:33 2020 by root via cibadmin on clubionic01.private 3 nodes configured 1 resource configured Online: [ clubionic01.private clubionic02.private clubionic03.private ] Active resources: - fence_clubionic (stonith:fence_scsi): Started clubionic01.private + fence_clubionic (stonith:fence_scsi): Started clubionic01.private (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist --in --read-keys --device=/dev/sda - LIO-ORG cluster.bionic. 4.0 - Peripheral device type: disk - PR generation=0x0, there are NO registered reservation keys + LIO-ORG cluster.bionic. 4.0 + Peripheral device type: disk + PR generation=0x0, there
[Ubuntu-ha] [Bug 1865523] Re: [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1
** No longer affects: pacemaker (Ubuntu) ** No longer affects: pacemaker (Ubuntu Bionic) ** Description changed: + OBS: I have split this bug into 2 bugs: + - fence-agents (this) and pacemaker (LP: #1866119) + SRU: fence-agents [Impact] * fence_scsi is not currently working in a share disk environment * all clusters relying in fence_scsi and/or fence_scsi + watchdog won't be able to start the fencing agents OR, in worst case scenarios, the fence_scsi agent might start but won't make scsi reservations in the shared scsi disk. [Test Case] * having a 3-node setup, nodes called "clubionic01, clubionic02, clubionic03", with a shared scsi disk (fully supporting persistent reservations) /dev/sda, one might try the following command: sudo fence_scsi --verbose -n clubionic01 -d /dev/sda -k 3abe -o off from nodes "clubionic02 or clubionic03" and check if the reservation worked: (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist --in --read-keys --device=/dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x0, there are NO registered reservation keys (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist -r /dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x0, there is NO reservation held * having a 3-node setup, nodes called "clubionic01, clubionic02, clubionic03", with a shared scsi disk (fully supporting persistent reservations) /dev/sda, with corosync and pacemaker operational and running, one might try: rafaeldtinoco@clubionic01:~$ crm configure crm(live)configure# property stonith-enabled=on crm(live)configure# property stonith-action=off crm(live)configure# property no-quorum-policy=stop crm(live)configure# property have-watchdog=true crm(live)configure# property symmetric-cluster=true crm(live)configure# commit crm(live)configure# end crm(live)# end rafaeldtinoco@clubionic01:~$ crm configure primitive fence_clubionic \ stonith:fence_scsi params \ pcmk_host_list="clubionic01 clubionic02 clubionic03" \ devices="/dev/sda" \ meta provides=unfencing And see that crm_mon won't show fence_clubionic resource operational. [Regression Potential] - * Comments #3 and #4 show this new version fully working. - - * This fix has a potential of breaking other "nowadays working" fencing agent. If that happens, I suggest that ones affected revert previous to previous package AND open a bug against either pacemaker and/or fence-agents. + * Comments #3 and #4 show this new version fully working. + + * This fix has a potential of breaking other "nowadays working" fencing + agent. If that happens, I suggest that ones affected revert previous to + previous package AND open a bug against either pacemaker and/or fence- + agents. * Judging by this issue, it is very likely that any Ubuntu user that have tried using fence_scsi has probably migrated to a newer version because fence_scsi agent is broken since its release. * The way I fixed fence_scsi was this: I packaged pacemaker in latest 1.1.X version and kept it "vanilla" so I could bisect fence-agents. At that moment I realized that bisecting was going to be hard because there were multiple issues, not only one. I backported the latest fence-agents together with Pacemaker 1.1.19-0 and saw that it worked. From then on, I bisected the following intervals: 4.3.0 .. 4.4.0 (eoan - working) 4.2.0 .. 4.3.0 4.1.0 .. 4.2.0 4.0.25 .. 4.1.0 (bionic - not working) In each of those intervals I discovered issues. For example, Using 4.3.0 I faced problems so I had to backport fixes that were in between 4.4.0 and 4.3.0. Then, backporting 4.2.0, I faced issues so I had to backport fixes from the 4.3.0 <-> 4.2.0 interval. I did this until I was at 4.0.25 version, current Bionic fence-agents version. [Other Info] * Original Description: Trying to setup a cluster with an iscsi shared disk, using fence_scsi as the fencing mechanism, I realized that fence_scsi is not working in Ubuntu Bionic. I first thought it was related to Azure environment (LP: #1864419), where I was trying this environment, but then, trying locally, I figured out that somehow pacemaker 1.1.18 is not fencing the shared scsi disk properly. Note: I was able to "backport" vanilla 1.1.19 from upstream and fence_scsi worked. I have then tried 1.1.18 without all quilt patches and it didnt work as well. I think that bisecting 1.1.18 <-> 1.1.19 might tell us which commit has fixed the behaviour needed by the fence_scsi agent. (k)rafaeldtinoco@clubionic01:~$ crm conf show node 1: clubionic01.private node 2: clubionic02.private node 3: clubionic03.private primitive fence_clubionic stonith:fence_scsi \ params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \
[Ubuntu-ha] [Bug 1866119] [NEW] [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1
Public bug reported: OBS: This bug was originally into LP: #1865523 but it was split. SRU: pacemaker [Impact] * fence_scsi is not currently working in a share disk environment * all clusters relying in fence_scsi and/or fence_scsi + watchdog won't be able to start the fencing agents OR, in worst case scenarios, the fence_scsi agent might start but won't make scsi reservations in the shared scsi disk. * this bug is taking care of pacemaker 1.1.18 issues with fence_scsi, since the later was fixed at LP: #1865523. [Test Case] * having a 3-node setup, nodes called "clubionic01, clubionic02, clubionic03", with a shared scsi disk (fully supporting persistent reservations) /dev/sda, with corosync and pacemaker operational and running, one might try: rafaeldtinoco@clubionic01:~$ crm configure crm(live)configure# property stonith-enabled=on crm(live)configure# property stonith-action=off crm(live)configure# property no-quorum-policy=stop crm(live)configure# property have-watchdog=true crm(live)configure# commit crm(live)configure# end crm(live)# end rafaeldtinoco@clubionic01:~$ crm configure primitive fence_clubionic \ stonith:fence_scsi params \ pcmk_host_list="clubionic01 clubionic02 clubionic03" \ devices="/dev/sda" \ meta provides=unfencing And see the following errors: Failed Actions: * fence_clubionic_start_0 on clubionic02 'unknown error' (1): call=6, status=Error, exitreason='', last-rc-change='Wed Mar 4 19:53:12 2020', queued=0ms, exec=1105ms * fence_clubionic_start_0 on clubionic03 'unknown error' (1): call=6, status=Error, exitreason='', last-rc-change='Wed Mar 4 19:53:13 2020', queued=0ms, exec=1109ms * fence_clubionic_start_0 on clubionic01 'unknown error' (1): call=6, status=Error, exitreason='', last-rc-change='Wed Mar 4 19:53:11 2020', queued=0ms, exec=1108ms and corosync.log will show: warning: unpack_rsc_op_failure: Processing failed op start for fence_clubionic on clubionic01: unknown error (1) [Regression Potential] * LP: #1865523 shows fence_scsi fully operational after SRU for that bug is done. * LP: #1865523 used pacemaker 1.1.19 (vanilla) in order to fix fence_scsi. * TODO [Other Info] * Original Description: Trying to setup a cluster with an iscsi shared disk, using fence_scsi as the fencing mechanism, I realized that fence_scsi is not working in Ubuntu Bionic. I first thought it was related to Azure environment (LP: #1864419), where I was trying this environment, but then, trying locally, I figured out that somehow pacemaker 1.1.18 is not fencing the shared scsi disk properly. Note: I was able to "backport" vanilla 1.1.19 from upstream and fence_scsi worked. I have then tried 1.1.18 without all quilt patches and it didnt work as well. I think that bisecting 1.1.18 <-> 1.1.19 might tell us which commit has fixed the behaviour needed by the fence_scsi agent. (k)rafaeldtinoco@clubionic01:~$ crm conf show node 1: clubionic01.private node 2: clubionic02.private node 3: clubionic03.private primitive fence_clubionic stonith:fence_scsi \ params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ meta provides=unfencing property cib-bootstrap-options: \ have-watchdog=false \ dc-version=1.1.18-2b07d5c5a9 \ cluster-infrastructure=corosync \ cluster-name=clubionic \ stonith-enabled=on \ stonith-action=off \ no-quorum-policy=stop \ symmetric-cluster=true (k)rafaeldtinoco@clubionic02:~$ sudo crm_mon -1 Stack: corosync Current DC: clubionic01.private (version 1.1.18-2b07d5c5a9) - partition with quorum Last updated: Mon Mar 2 15:55:30 2020 Last change: Mon Mar 2 15:45:33 2020 by root via cibadmin on clubionic01.private 3 nodes configured 1 resource configured Online: [ clubionic01.private clubionic02.private clubionic03.private ] Active resources: fence_clubionic (stonith:fence_scsi): Started clubionic01.private (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist --in --read-keys --device=/dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x0, there are NO registered reservation keys (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist -r /dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x0, there is NO reservation held ** Affects: pacemaker (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: pacemaker (Ubuntu Bionic) Importance: Undecided Status: In Progress ** Also affects: pacemaker (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: pacemaker (Ubuntu) Status: New => Fix Released ** Changed in: pacemaker (Ubuntu Bionic) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1866119 Title: [bionic] fence_scsi not working
[Ubuntu-ha] [Bug 1865523] Re: [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1
** Description changed: + SRU: fence-agents + + [Impact] + + * fence_scsi is not currently working in a share disk environment + + * all clusters relying in fence_scsi and/or fence_scsi + watchdog won't + be able to start the fencing agents OR, in worst case scenarios, the + fence_scsi agent might start but won't make scsi reservations in the + shared scsi disk. + + [Test Case] + + * having a 3-node setup, nodes called "clubionic01, clubionic02, + clubionic03", with a shared scsi disk (fully supporting persistent + reservations) /dev/sda, one might try the following command: + + sudo fence_scsi --verbose -n clubionic01 -d /dev/sda -k 3abe -o off + + from nodes "clubionic02 or clubionic03" and check if the reservation + worked: + + (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist --in --read-keys --device=/dev/sda + LIO-ORG cluster.bionic. 4.0 + Peripheral device type: disk + PR generation=0x0, there are NO registered reservation keys + + (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist -r /dev/sda + LIO-ORG cluster.bionic. 4.0 + Peripheral device type: disk + PR generation=0x0, there is NO reservation held + + * having a 3-node setup, nodes called "clubionic01, clubionic02, + clubionic03", with a shared scsi disk (fully supporting persistent + reservations) /dev/sda, with corosync and pacemaker operational and + running, one might try: + + rafaeldtinoco@clubionic01:~$ crm configure + crm(live)configure# property stonith-enabled=on + crm(live)configure# property stonith-action=off + crm(live)configure# property no-quorum-policy=stop + crm(live)configure# property have-watchdog=true + crm(live)configure# property symmetric-cluster=true + crm(live)configure# commit + crm(live)configure# end + crm(live)# end + + rafaeldtinoco@clubionic01:~$ crm configure primitive fence_clubionic \ + stonith:fence_scsi params \ + pcmk_host_list="clubionic01 clubionic02 clubionic03" \ + devices="/dev/sda" \ + meta provides=unfencing + + And see that crm_mon won't show fence_clubionic resource operational. + + [Regression Potential] + + * Judging by this issue, it is very likely that any Ubuntu user that + have tried using fence_scsi has probably migrated to a newer version + because fence_scsi agent is broken since its release. + + * The way I fixed fence_scsi was this: + + I packaged pacemaker in latest 1.1.X version and kept it "vanilla" so I + could bisect fence-agents. At that moment I realized that bisecting was + going to be hard because there were multiple issues, not only one. I + backported the latest fence-agents together with Pacemaker 1.1.19-0 and + saw that it worked. + + From then on, I bisected the following intervals: + + 4.3.0 .. 4.4.0 (eoan - working) + 4.2.0 .. 4.3.0 + 4.1.0 .. 4.2.0 + 4.0.25 .. 4.1.0 (bionic - not working) + + In each of those intervals I discovered issues. For example, Using 4.3.0 + I faced problems so I had to backport fixes that were in between 4.4.0 + and 4.3.0. Then, backporting 4.2.0, I faced issues so I had to backport + fixes from the 4.3.0 <-> 4.2.0 interval. I did this until I was at + 4.0.25 version, current Bionic fence-agents version. + + [Other Info] + + * Original Description: + Trying to setup a cluster with an iscsi shared disk, using fence_scsi as the fencing mechanism, I realized that fence_scsi is not working in Ubuntu Bionic. I first thought it was related to Azure environment (LP: #1864419), where I was trying this environment, but then, trying locally, I figured out that somehow pacemaker 1.1.18 is not fencing the shared scsi disk properly. Note: I was able to "backport" vanilla 1.1.19 from upstream and fence_scsi worked. I have then tried 1.1.18 without all quilt patches and it didnt work as well. I think that bisecting 1.1.18 <-> 1.1.19 might tell us which commit has fixed the behaviour needed by the fence_scsi agent. (k)rafaeldtinoco@clubionic01:~$ crm conf show node 1: clubionic01.private node 2: clubionic02.private node 3: clubionic03.private primitive fence_clubionic stonith:fence_scsi \ - params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ - meta provides=unfencing + params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ + meta provides=unfencing property cib-bootstrap-options: \ - have-watchdog=false \ - dc-version=1.1.18-2b07d5c5a9 \ - cluster-infrastructure=corosync \ - cluster-name=clubionic \ - stonith-enabled=on \ - stonith-action=off \ - no-quorum-policy=stop \ - symmetric-cluster=true + have-watchdog=false \ + dc-version=1.1.18-2b07d5c5a9 \ + cluster-infrastructure=corosync \ + cluster-name=clubionic \ + stonith-enabled=on \ + stonith-action=off \ + no-quorum-policy=stop \ + symmetric-cluster=true
[Ubuntu-ha] [Bug 1865523] Re: [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1
# For Ubuntu Bionic: Okay, after bisecting fence-scsi and monitoring all its functions I was able to isolate the patches that I need to take to bionic to make it compatible with existing version and, at the same time, operational: Note: all tests were conducted with Pacemaker v1.1.19-0ubuntu1 and this is not the default in Ubuntu Bionic. I have maintained "vanilla" Pacemaker v1.1.19 in order to better isolate all fixes for fence-agents. Now I'm able to create a fixed fence-agent package for Ubuntu Bionic AND fix Pacemaker. # Ubuntu Bionic SRU: Fence Agents v4.0.25 PLUS the following fixes/commits ordered by date: commit 81b8370844f5aecaee5e7178d82670c70399d824 Author: Oyvind Albrigtsen Date: Mon Jul 24 14:12:15 2017 fence_scsi: add FIPS support commit eae9d029b7073e7eb8c7ba4df9ec19b755a8f603 Author: Oyvind Albrigtsen Date: Wed Sep 27 12:26:38 2017 fix for ignored options commit c6f29a653114523e9ac3644aed958b4bb43f3b41 Author: Oyvind Albrigtsen Date: Wed Sep 27 12:42:39 2017 Maintain ABI compatibility for external agents commit 746fd55b061aa28b27aac5a1bb38714a95812592 Author: Reid Wahl Date: Fri Apr 6 18:31:30 2018 Low: fence_scsi: Remove period from cmd string commit bec154345d2291c9051c16277de9054387dc9707 Author: Oyvind Albrigtsen Date: Thu Apr 19 11:30:53 2018 fence_scsi: fix plug-parameter and keep support for nodename to avoid regressions commit 335aca4e54e4ec46b9b5d86ef30a7d9348e6a216 Author: Valentin Vidic Date: Wed May 23 12:51:23 2018 fence_scsi: fix python3 encoding error #206 commit f77297b654586bf539e78957f26cae1d22c6f081 Author: Oyvind Albrigtsen Date: Fri Nov 2 08:24:56 2018 fence_scsi: fix incorrect SCSI key when node ID is 10 or higher The last four digits of the SCSI key will be zero padded digit between -0009. commit 1c4a64ca803831b44c96c75022abe5bb8713cd1a Author: Oyvind Albrigtsen Date: Wed May 22 08:13:34 2019 fence_scsi: detect node ID using new format, and fallback to old format before failing -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1865523 Title: [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1 Status in fence-agents package in Ubuntu: Fix Released Status in pacemaker package in Ubuntu: Fix Released Status in fence-agents source package in Bionic: Confirmed Status in pacemaker source package in Bionic: Confirmed Status in fence-agents source package in Disco: Confirmed Status in fence-agents source package in Eoan: Fix Released Status in fence-agents source package in Focal: Fix Released Bug description: Trying to setup a cluster with an iscsi shared disk, using fence_scsi as the fencing mechanism, I realized that fence_scsi is not working in Ubuntu Bionic. I first thought it was related to Azure environment (LP: #1864419), where I was trying this environment, but then, trying locally, I figured out that somehow pacemaker 1.1.18 is not fencing the shared scsi disk properly. Note: I was able to "backport" vanilla 1.1.19 from upstream and fence_scsi worked. I have then tried 1.1.18 without all quilt patches and it didnt work as well. I think that bisecting 1.1.18 <-> 1.1.19 might tell us which commit has fixed the behaviour needed by the fence_scsi agent. (k)rafaeldtinoco@clubionic01:~$ crm conf show node 1: clubionic01.private node 2: clubionic02.private node 3: clubionic03.private primitive fence_clubionic stonith:fence_scsi \ params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ meta provides=unfencing property cib-bootstrap-options: \ have-watchdog=false \ dc-version=1.1.18-2b07d5c5a9 \ cluster-infrastructure=corosync \ cluster-name=clubionic \ stonith-enabled=on \ stonith-action=off \ no-quorum-policy=stop \ symmetric-cluster=true (k)rafaeldtinoco@clubionic02:~$ sudo crm_mon -1 Stack: corosync Current DC: clubionic01.private (version 1.1.18-2b07d5c5a9) - partition with quorum Last updated: Mon Mar 2 15:55:30 2020 Last change: Mon Mar 2 15:45:33 2020 by root via cibadmin on clubionic01.private 3 nodes configured 1 resource configured Online: [ clubionic01.private clubionic02.private clubionic03.private ] Active resources: fence_clubionic(stonith:fence_scsi): Started clubionic01.private (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist --in --read-keys --device=/dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x0, there are NO registered reservation keys (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist -r /dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x0, there is NO reservation held To manage notifications
[Ubuntu-ha] [Bug 1865523] Re: [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1
# Demonstration of fence_scsi agent working in Bionic: (k)rafaeldtinoco@clubionic01:~/.../upstream$ sudo dpkg -i ./*.deb dpkg: warning: downgrading fence-agents from 4.4.0-2 to 4.0.25-2ubuntu1 (Reading database ... 85434 files and directories currently installed.) Preparing to unpack .../fence-agents_4.0.25-2ubuntu1_amd64.deb ... Unpacking fence-agents (4.0.25-2ubuntu1) over (4.4.0-2) ... Preparing to unpack .../fence-agents_4.4.0-2_amd64.deb ... Unpacking fence-agents (4.4.0-2) over (4.0.25-2ubuntu1) ... Setting up fence-agents (4.4.0-2) ... Processing triggers for man-db (2.8.3-2ubuntu0.1) ... (k)rafaeldtinoco@clubionic01:~/.../upstream$ sudo sg_persist --in --read-keys --device=/dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x0, there are NO registered reservation keys (k)rafaeldtinoco@clubionic01:~/.../upstream$ systemctl restart pacemaker (k)rafaeldtinoco@clubionic02:~/.../upstream$ crm_mon -1 Stack: corosync Current DC: clubionic03.private (version 1.1.19-1.1.19) - partition with quorum Last updated: Tue Mar 3 21:16:04 2020 Last change: Tue Mar 3 20:25:56 2020 by root via cibadmin on clubionic01.private 3 nodes configured 1 resource configured Online: [ clubionic01.private clubionic02.private clubionic03.private ] Active resources: fence_clubionic(stonith:fence_scsi): Started clubionic01.private (k)rafaeldtinoco@clubionic01:~/.../upstream$ sudo sg_persist --in --read-keys --device=/dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x3, 3 registered reservation keys follow: 0x3abe 0x3abe0001 0x3abe0002 (k)rafaeldtinoco@clubionic01:~/.../upstream$ sudo sg_persist -r /dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x3, Reservation follows: Key=0x3abe0001 scope: LU_SCOPE, type: Write Exclusive, registrants only -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1865523 Title: [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1 Status in fence-agents package in Ubuntu: Fix Released Status in pacemaker package in Ubuntu: Fix Released Status in fence-agents source package in Bionic: Confirmed Status in pacemaker source package in Bionic: Confirmed Status in fence-agents source package in Disco: Confirmed Status in fence-agents source package in Eoan: Fix Released Status in fence-agents source package in Focal: Fix Released Bug description: Trying to setup a cluster with an iscsi shared disk, using fence_scsi as the fencing mechanism, I realized that fence_scsi is not working in Ubuntu Bionic. I first thought it was related to Azure environment (LP: #1864419), where I was trying this environment, but then, trying locally, I figured out that somehow pacemaker 1.1.18 is not fencing the shared scsi disk properly. Note: I was able to "backport" vanilla 1.1.19 from upstream and fence_scsi worked. I have then tried 1.1.18 without all quilt patches and it didnt work as well. I think that bisecting 1.1.18 <-> 1.1.19 might tell us which commit has fixed the behaviour needed by the fence_scsi agent. (k)rafaeldtinoco@clubionic01:~$ crm conf show node 1: clubionic01.private node 2: clubionic02.private node 3: clubionic03.private primitive fence_clubionic stonith:fence_scsi \ params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ meta provides=unfencing property cib-bootstrap-options: \ have-watchdog=false \ dc-version=1.1.18-2b07d5c5a9 \ cluster-infrastructure=corosync \ cluster-name=clubionic \ stonith-enabled=on \ stonith-action=off \ no-quorum-policy=stop \ symmetric-cluster=true (k)rafaeldtinoco@clubionic02:~$ sudo crm_mon -1 Stack: corosync Current DC: clubionic01.private (version 1.1.18-2b07d5c5a9) - partition with quorum Last updated: Mon Mar 2 15:55:30 2020 Last change: Mon Mar 2 15:45:33 2020 by root via cibadmin on clubionic01.private 3 nodes configured 1 resource configured Online: [ clubionic01.private clubionic02.private clubionic03.private ] Active resources: fence_clubionic(stonith:fence_scsi): Started clubionic01.private (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist --in --read-keys --device=/dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x0, there are NO registered reservation keys (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist -r /dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x0, there is NO reservation held To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fence-agents/+bug/1865523/+subscriptions
[Ubuntu-ha] [Bug 1865523] Re: [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1
Now I'm going to work with this package and check needed Pacemaker fixes. After that I'm going to propose both merges together. -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1865523 Title: [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1 Status in fence-agents package in Ubuntu: Fix Released Status in pacemaker package in Ubuntu: Fix Released Status in fence-agents source package in Bionic: Confirmed Status in pacemaker source package in Bionic: Confirmed Status in fence-agents source package in Disco: Confirmed Status in fence-agents source package in Eoan: Fix Released Status in fence-agents source package in Focal: Fix Released Bug description: Trying to setup a cluster with an iscsi shared disk, using fence_scsi as the fencing mechanism, I realized that fence_scsi is not working in Ubuntu Bionic. I first thought it was related to Azure environment (LP: #1864419), where I was trying this environment, but then, trying locally, I figured out that somehow pacemaker 1.1.18 is not fencing the shared scsi disk properly. Note: I was able to "backport" vanilla 1.1.19 from upstream and fence_scsi worked. I have then tried 1.1.18 without all quilt patches and it didnt work as well. I think that bisecting 1.1.18 <-> 1.1.19 might tell us which commit has fixed the behaviour needed by the fence_scsi agent. (k)rafaeldtinoco@clubionic01:~$ crm conf show node 1: clubionic01.private node 2: clubionic02.private node 3: clubionic03.private primitive fence_clubionic stonith:fence_scsi \ params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ meta provides=unfencing property cib-bootstrap-options: \ have-watchdog=false \ dc-version=1.1.18-2b07d5c5a9 \ cluster-infrastructure=corosync \ cluster-name=clubionic \ stonith-enabled=on \ stonith-action=off \ no-quorum-policy=stop \ symmetric-cluster=true (k)rafaeldtinoco@clubionic02:~$ sudo crm_mon -1 Stack: corosync Current DC: clubionic01.private (version 1.1.18-2b07d5c5a9) - partition with quorum Last updated: Mon Mar 2 15:55:30 2020 Last change: Mon Mar 2 15:45:33 2020 by root via cibadmin on clubionic01.private 3 nodes configured 1 resource configured Online: [ clubionic01.private clubionic02.private clubionic03.private ] Active resources: fence_clubionic(stonith:fence_scsi): Started clubionic01.private (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist --in --read-keys --device=/dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x0, there are NO registered reservation keys (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist -r /dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x0, there is NO reservation held To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fence-agents/+bug/1865523/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1865523] Re: [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1
# Demonstration of fence_scsi fencing a node: (k)rafaeldtinoco@clubionic03:~/.../upstream$ cat /etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp # iscsi auto eth1 iface eth1 inet static address 10.250.1.12/24 # private auto eth2 iface eth2 inet static address 10.250.3.12/24 # public auto eth3 iface eth3 inet static address 10.250.98.12/24 (k)rafaeldtinoco@clubionic03:~/.../upstream$ sudo iptables -A INPUT -i eth2 -j DROP (k)rafaeldtinoco@clubionic01:~$ crm_mon -1 Stack: corosync Current DC: clubionic01.private (version 1.1.19-1.1.19) - partition with quorum Last updated: Tue Mar 3 21:24:55 2020 Last change: Tue Mar 3 20:25:56 2020 by root via cibadmin on clubionic01.private 3 nodes configured 1 resource configured Online: [ clubionic01.private clubionic02.private ] OFFLINE: [ clubionic03.private ] Active resources: fence_clubionic(stonith:fence_scsi): Started clubionic01.private (k)rafaeldtinoco@clubionic03:~/.../upstream$ sudo sg_persist --in --read-keys --device=/dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x4, 2 registered reservation keys follow: 0x3abe 0x3abe0001 (k)rafaeldtinoco@clubionic03:~/.../upstream$ sudo dd if=/dev/zero of=/dev/sda bs=1M count=1 [ 3301.867294] print_req_error: critical nexus error, dev sda, sector 0 [ 3301.868543] Buffer I/O error on dev sda, logical block 0, lost async page write [ 3301.869956] Buffer I/O error on dev sda, logical block 1, lost async page write [ 3301.871430] Buffer I/O error on dev sda, logical block 2, lost async page write [ 3301.872929] Buffer I/O error on dev sda, logical block 3, lost async page write [ 3301.874448] Buffer I/O error on dev sda, logical block 4, lost async page write [ 3301.875963] Buffer I/O error on dev sda, logical block 5, lost async page write [ 3301.877486] Buffer I/O error on dev sda, logical block 6, lost async page write [ 3301.879000] Buffer I/O error on dev sda, logical block 7, lost async page write [ 3301.880481] Buffer I/O error on dev sda, logical block 8, lost async page write [ 3301.882014] Buffer I/O error on dev sda, logical block 9, lost async page write 1+0 records in 1+0 records out 1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0227557 s, 46.1 MB/s -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1865523 Title: [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1 Status in fence-agents package in Ubuntu: Fix Released Status in pacemaker package in Ubuntu: Fix Released Status in fence-agents source package in Bionic: Confirmed Status in pacemaker source package in Bionic: Confirmed Status in fence-agents source package in Disco: Confirmed Status in fence-agents source package in Eoan: Fix Released Status in fence-agents source package in Focal: Fix Released Bug description: Trying to setup a cluster with an iscsi shared disk, using fence_scsi as the fencing mechanism, I realized that fence_scsi is not working in Ubuntu Bionic. I first thought it was related to Azure environment (LP: #1864419), where I was trying this environment, but then, trying locally, I figured out that somehow pacemaker 1.1.18 is not fencing the shared scsi disk properly. Note: I was able to "backport" vanilla 1.1.19 from upstream and fence_scsi worked. I have then tried 1.1.18 without all quilt patches and it didnt work as well. I think that bisecting 1.1.18 <-> 1.1.19 might tell us which commit has fixed the behaviour needed by the fence_scsi agent. (k)rafaeldtinoco@clubionic01:~$ crm conf show node 1: clubionic01.private node 2: clubionic02.private node 3: clubionic03.private primitive fence_clubionic stonith:fence_scsi \ params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ meta provides=unfencing property cib-bootstrap-options: \ have-watchdog=false \ dc-version=1.1.18-2b07d5c5a9 \ cluster-infrastructure=corosync \ cluster-name=clubionic \ stonith-enabled=on \ stonith-action=off \ no-quorum-policy=stop \ symmetric-cluster=true (k)rafaeldtinoco@clubionic02:~$ sudo crm_mon -1 Stack: corosync Current DC: clubionic01.private (version 1.1.18-2b07d5c5a9) - partition with quorum Last updated: Mon Mar 2 15:55:30 2020 Last change: Mon Mar 2 15:45:33 2020 by root via cibadmin on clubionic01.private 3 nodes configured 1 resource configured Online: [ clubionic01.private clubionic02.private clubionic03.private ] Active resources: fence_clubionic(stonith:fence_scsi): Started clubionic01.private (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist --in --read-keys --device=/dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type:
[Ubuntu-ha] [Bug 1828228] Re: corosync fails to start in unprivileged containers - autopkgtest failure
** Merge proposal unlinked: https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/corosync/+git/corosync/+merge/379581 -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to corosync in Ubuntu. https://bugs.launchpad.net/bugs/1828228 Title: corosync fails to start in unprivileged containers - autopkgtest failure Status in Auto Package Testing: Invalid Status in corosync package in Ubuntu: Fix Released Status in pacemaker package in Ubuntu: Fix Released Status in pcs package in Ubuntu: In Progress Bug description: Currently pacemaker v2 fails to start in armhf containers (and by extension corosync too). I found that it is reproducible locally, and that I had to bump a few limits to get it going. Specifically I did: 1) bump memlock limits 2) bump rmem_max limits = 1) Bump memlock limits = I have no idea, which one of these finally worked, and/or is sufficient. A bit of a whack-a-mole. cat >>/etc/security/limits.conf
[Ubuntu-ha] [Bug 1864116] Re: Package: pacemaker (debian: 2.0.3-3, ubuntu: 2.0.1-5ubuntu5) needs merge
** Merge proposal linked: https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/pacemaker/+git/pacemaker/+merge/379595 -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1864116 Title: Package: pacemaker (debian: 2.0.3-3, ubuntu: 2.0.1-5ubuntu5) needs merge Status in pacemaker package in Ubuntu: In Progress Bug description: Package: pacemaker (debian: 2.0.3-3, ubuntu: 2.0.1-5ubuntu5) needs merge To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1864116/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1828228] Re: corosync fails to start in unprivileged containers - autopkgtest failure
** Merge proposal unlinked: https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/pacemaker/+git/pacemaker/+merge/379595 -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to corosync in Ubuntu. https://bugs.launchpad.net/bugs/1828228 Title: corosync fails to start in unprivileged containers - autopkgtest failure Status in Auto Package Testing: Invalid Status in corosync package in Ubuntu: Fix Released Status in pacemaker package in Ubuntu: Fix Released Status in pcs package in Ubuntu: In Progress Bug description: Currently pacemaker v2 fails to start in armhf containers (and by extension corosync too). I found that it is reproducible locally, and that I had to bump a few limits to get it going. Specifically I did: 1) bump memlock limits 2) bump rmem_max limits = 1) Bump memlock limits = I have no idea, which one of these finally worked, and/or is sufficient. A bit of a whack-a-mole. cat >>/etc/security/limits.conf
[Ubuntu-ha] [Bug 1864116] [NEW] Package: pacemaker (debian: 2.0.3-3, ubuntu: 2.0.1-5ubuntu5) needs merge
Public bug reported: Package: pacemaker (debian: 2.0.3-3, ubuntu: 2.0.1-5ubuntu5) needs merge ** Affects: pacemaker (Ubuntu) Importance: Medium Assignee: Rafael David Tinoco (rafaeldtinoco) Status: In Progress ** Changed in: pacemaker (Ubuntu) Status: New => In Progress ** Changed in: pacemaker (Ubuntu) Importance: Undecided => Medium ** Changed in: pacemaker (Ubuntu) Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco) -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1864116 Title: Package: pacemaker (debian: 2.0.3-3, ubuntu: 2.0.1-5ubuntu5) needs merge Status in pacemaker package in Ubuntu: In Progress Bug description: Package: pacemaker (debian: 2.0.3-3, ubuntu: 2.0.1-5ubuntu5) needs merge To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1864116/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1864087] Re: Package: corosync (debian: 3.0.3-2, ubuntu: 3.0.2-1ubuntu2) needs merge
corosync (3.0.3-2ubuntu1) focal; urgency=medium * Merge with Debian unstable. Remaining changes: - Skip autopkgtest for unprivileged containers: (LP #1828228) + d/t/control: mark tests as skippable + d/t/cfgtool: skip if memlock can't be set to unlimited by uid 0 + d/t/quorumtool: skip if memlock can't be set to unlimited by uid 0 -- Rafael David Tinoco Thu, 20 Feb 2020 17:57:22 + corosync (3.0.3-2) unstable; urgency=medium * [d0a06e5] Separate the autopkgtests and make them generate artifacts * [8680d48] Run Salsa CI reprotest with diffoscope * [1d89c4f] Recognize the autopkgtest artifacts in Salsa CI * [8e09226] New patch: man: move cmap_keys man page from section 8 to 7 -- Ferenc Wágner Sat, 04 Jan 2020 14:07:31 +0100 corosync (3.0.3-1) unstable; urgency=medium * [d103a33] New upstream release (3.0.3) * [e6f6831] Refresh our patches * [f1e85a3] Enable nozzle support * [19d3dd3] Package the votequorum simulator in corosync-vqsim * [8ae3235] Update Standards-Version to 4.4.1 (no changes required) * [bfd9560] Advertise Rules-Requires-Root: no -- Ferenc Wágner Sat, 07 Dec 2019 23:02:16 +0100 corosync (3.0.2-1ubuntu2) focal; urgency=medium * Rebuild for libsnmp35. -- Rafael David Tinoco Tue, 14 Jan 2020 17:55:39 + corosync (3.0.2-1ubuntu1) focal; urgency=medium * Merge with Debian unstable. Remaining changes: - Skip autopkgtest for unprivileged containers: (LP #1828228) + d/t/control: mark corosync test as skippable + d/t/corosync: skip if memlock can't be set to unlimited by root -- Rafael David Tinoco Mon, 04 Nov 2019 17:37:30 -0300 -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to corosync in Ubuntu. https://bugs.launchpad.net/bugs/1864087 Title: Package: corosync (debian: 3.0.3-2, ubuntu: 3.0.2-1ubuntu2) needs merge Status in corosync package in Ubuntu: In Progress Bug description: Package: corosync (debian: 3.0.3-2, ubuntu: 3.0.2-1ubuntu2) needs merge To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1864087/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1864087] [NEW] Package: corosync (debian: 3.0.3-2, ubuntu: 3.0.2-1ubuntu2) needs merge
Public bug reported: Package: corosync (debian: 3.0.3-2, ubuntu: 3.0.2-1ubuntu2) needs merge ** Affects: corosync (Ubuntu) Importance: Medium Assignee: Rafael David Tinoco (rafaeldtinoco) Status: In Progress ** Changed in: corosync (Ubuntu) Status: New => In Progress ** Changed in: corosync (Ubuntu) Importance: Undecided => Medium ** Changed in: corosync (Ubuntu) Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco) -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to corosync in Ubuntu. https://bugs.launchpad.net/bugs/1864087 Title: Package: corosync (debian: 3.0.3-2, ubuntu: 3.0.2-1ubuntu2) needs merge Status in corosync package in Ubuntu: In Progress Bug description: Package: corosync (debian: 3.0.3-2, ubuntu: 3.0.2-1ubuntu2) needs merge To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1864087/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1863677] [NEW] fence_scsi needs lvm2 package so it should depend on it
Public bug reported:
Playing with fence_scsi I have noticed that one of my images did not
have lvm2 package installed. With that, the following error ocurred:
$ sudo fence_scsi -n clufocal03 --action=status
2020-02-17 19:57:02,324 ERROR: Unable to run /sbin/vgs --noheadings --separator
: --sort pv_uuid --options vg_attr,pv_name --config 'global { locking_type = 0
} devices { preferred_names = [ "^/dev/dm" ] }'
when trying to scsi fence one of my nodes.
fence-agents should depend and/or suggest all packages it depends on for
the correct execution of provided agents.
** Affects: fence-agents (Ubuntu)
Importance: Medium
Assignee: Rafael David Tinoco (rafaeldtinoco)
Status: Confirmed
** Changed in: fence-agents (Ubuntu)
Status: New => Confirmed
** Changed in: fence-agents (Ubuntu)
Importance: Undecided => Medium
** Changed in: fence-agents (Ubuntu)
Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco)
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1863677
Title:
fence_scsi needs lvm2 package so it should depend on it
Status in fence-agents package in Ubuntu:
Confirmed
Bug description:
Playing with fence_scsi I have noticed that one of my images did not
have lvm2 package installed. With that, the following error ocurred:
$ sudo fence_scsi -n clufocal03 --action=status
2020-02-17 19:57:02,324 ERROR: Unable to run /sbin/vgs --noheadings
--separator : --sort pv_uuid --options vg_attr,pv_name --config 'global {
locking_type = 0 } devices { preferred_names = [ "^/dev/dm" ] }'
when trying to scsi fence one of my nodes.
fence-agents should depend and/or suggest all packages it depends on
for the correct execution of provided agents.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fence-agents/+bug/1863677/+subscriptions
___
Mailing list: https://launchpad.net/~ubuntu-ha
Post to : ubuntu-ha@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-ha
More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1863437] Re: [focal] pacemaker i386 should drop a few i386 only packages
https://salsa.debian.org/ha-team/pacemaker/merge_requests/1 -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1863437 Title: [focal] pacemaker i386 should drop a few i386 only packages Status in pacemaker package in Ubuntu: In Progress Status in pacemaker source package in Focal: In Progress Bug description: When executing pacemaker i386 autopkgtests I realized that package "resource-agents" wasn't available for i386. When discussing this with @vorlon we came into the conclusion that some i386 only cluster packages could be removed from the repository, towards the effort of having *only the essential* packages available in i386 (to be run together with an amd64 host). IRC log: """ resource-agents i386 binary package the pacemaker binary is /not/ present on i386 in the release pocket that may have been an overly aggressive removal vorlon: are u keeping pacemaker because of dependencies ? yeah, I removed it when I shouldn't have (https://launchpad.net/ubuntu/focal/i386/pacemaker) rafaeldtinoco: pacemaker-dev is a build-dep of something else we need, see the referenced germinate output for full details https://people.canonical.com/~ubuntu-archive/germinate- output/i386.focal/i386+build-depends pacemaker-dev is a build-dep of dlm and libesmtp-dev is a build-dep of pacemaker, not the other way around (and dlm is a build-dep of lvm2) ah gotcha dlm -> corosync -> pacemaker so, even though I removed the binary in error from the release pocket, the right answer is still for pacemaker/i386 binary to go away (leaving only the -dev and lib packages) do you want me to fix that up, or do you want to? to fix that we should do like we did to samba ? yeah looks like the binaries you'll need to drop are pacemaker, pacemaker-cli-utils, pacemaker-remote and I'll remove those from -proposed right now, so that those don't hold up migration but I'll hold off on adding the hint until they're dropped from the source deal, and next hint ill do with proper branch """ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1863437/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1863437] Re: [focal] pacemaker i386 should drop a few i386 only packages
Upstream already had the following commit (since @vorlon opened the bug
in January):
commit 543574f18
Author: Ferenc Wágner
Date: Thu Jan 9 14:19:19 2020
Omit pacemaker{, -cli-utils, -remote} on Ubuntu/i386
Closes: #948379
diff --git a/debian/rules b/debian/rules
index 1d186d741..04acd7da2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,8 +11,14 @@ export DEB_LDFLAGS_MAINT_APPEND=-Wl,-z,defs
# Avoid useless dependencies in the utilities
export DEB_LDFLAGS_MAINT_APPEND+=-Wl,--as-needed
+# Ubuntu/i386 shrank into a compatibility layer not carrying the
+# dependencies of some of our binary packages (#948379):
+ifeq ($(shell dpkg-vendor --query vendor)/$(DEB_HOST_ARCH), Ubuntu/i386)
+UBUNTU_EXCLUDES = -Npacemaker -Npacemaker-cli-utils -Npacemaker-remote
+endif
+
%:
- dh $@ --with python3
+ dh $@ --with python3 $(UBUNTU_EXCLUDES)
# autoreconf options taken from autogen.sh
# without symlink usage (-s) to make --as-needed effective
I'll propose it to include: -Npacemaeker-resource-agents and we will be
good.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948379
** Bug watch added: Debian Bug tracker #948379
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948379
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed to pacemaker in Ubuntu.
https://bugs.launchpad.net/bugs/1863437
Title:
[focal] pacemaker i386 should drop a few i386 only packages
Status in pacemaker package in Ubuntu:
In Progress
Status in pacemaker source package in Focal:
In Progress
Bug description:
When executing pacemaker i386 autopkgtests I realized that package
"resource-agents" wasn't available for i386. When discussing this with
@vorlon we came into the conclusion that some i386 only cluster
packages could be removed from the repository, towards the effort of
having *only the essential* packages available in i386 (to be run
together with an amd64 host).
IRC log:
"""
resource-agents i386 binary package
the pacemaker binary is /not/ present on i386 in the release pocket
that may have been an overly aggressive removal
vorlon: are u keeping pacemaker because of dependencies ?
yeah, I removed it when I shouldn't have
(https://launchpad.net/ubuntu/focal/i386/pacemaker)
rafaeldtinoco: pacemaker-dev is a build-dep of something else we
need,
see the referenced germinate output for full details
https://people.canonical.com/~ubuntu-archive/germinate-
output/i386.focal/i386+build-depends
pacemaker-dev is a build-dep of dlm
and libesmtp-dev is a build-dep of pacemaker, not the other way
around
(and dlm is a build-dep of lvm2)
ah gotcha
dlm -> corosync -> pacemaker
so, even though I removed the binary in error from the release
pocket,
the right answer is still for pacemaker/i386 binary to go away (leaving only
the
-dev and lib packages)
do you want me to fix that up, or do you want to?
to fix that we should do like we did to samba ?
yeah
looks like the binaries you'll need to drop are pacemaker,
pacemaker-cli-utils, pacemaker-remote
and I'll remove those from -proposed right now, so that those don't
hold up migration
but I'll hold off on adding the hint until they're dropped from the
source
deal, and next hint ill do with proper branch
"""
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1863437/+subscriptions
___
Mailing list: https://launchpad.net/~ubuntu-ha
Post to : ubuntu-ha@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-ha
More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1863437] Re: [focal] pacemaker i386 should drop a few i386 only packages
Merged and uploaded. -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1863437 Title: [focal] pacemaker i386 should drop a few i386 only packages Status in pacemaker package in Ubuntu: In Progress Status in pacemaker source package in Focal: In Progress Bug description: When executing pacemaker i386 autopkgtests I realized that package "resource-agents" wasn't available for i386. When discussing this with @vorlon we came into the conclusion that some i386 only cluster packages could be removed from the repository, towards the effort of having *only the essential* packages available in i386 (to be run together with an amd64 host). IRC log: """ resource-agents i386 binary package the pacemaker binary is /not/ present on i386 in the release pocket that may have been an overly aggressive removal vorlon: are u keeping pacemaker because of dependencies ? yeah, I removed it when I shouldn't have (https://launchpad.net/ubuntu/focal/i386/pacemaker) rafaeldtinoco: pacemaker-dev is a build-dep of something else we need, see the referenced germinate output for full details https://people.canonical.com/~ubuntu-archive/germinate- output/i386.focal/i386+build-depends pacemaker-dev is a build-dep of dlm and libesmtp-dev is a build-dep of pacemaker, not the other way around (and dlm is a build-dep of lvm2) ah gotcha dlm -> corosync -> pacemaker so, even though I removed the binary in error from the release pocket, the right answer is still for pacemaker/i386 binary to go away (leaving only the -dev and lib packages) do you want me to fix that up, or do you want to? to fix that we should do like we did to samba ? yeah looks like the binaries you'll need to drop are pacemaker, pacemaker-cli-utils, pacemaker-remote and I'll remove those from -proposed right now, so that those don't hold up migration but I'll hold off on adding the hint until they're dropped from the source deal, and next hint ill do with proper branch """ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1863437/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1863437] Re: [focal] pacemaker i386 should drop a few i386 only packages
"fakeroot debian/rules build-arch" gives me: dpkg-deb: building package 'pacemaker-remote' in '../pacemaker-remote_2.0.1-5ubuntu5_i386.deb'. dpkg-deb: building package 'pacemaker' in '../pacemaker_2.0.1-5ubuntu5_i386.deb'. dpkg-deb: building package 'libcrmcluster29' in '../libcrmcluster29_2.0.1-5ubuntu5_i386.deb'. dpkg-deb: building package 'libcrmservice28' in '../libcrmservice28_2.0.1-5ubuntu5_i386.deb'. dpkg-deb: building package 'libpe-rules26' in '../libpe-rules26_2.0.1-5ubuntu5_i386.deb'. dpkg-deb: building package 'libpengine27' in '../libpengine27_2.0.1-5ubuntu5_i386.deb'. dpkg-deb: building package 'libtransitioner25' in '../libtransitioner25_2.0.1-5ubuntu5_i386.deb'. dpkg-deb: building package 'libpe-status28' in '../libpe-status28_2.0.1-5ubuntu5_i386.deb'. dpkg-deb: building package 'pacemaker-dev' in '../pacemaker-dev_2.0.1-5ubuntu5_i386.deb'. dpkg-deb: building package 'libcib27' in '../libcib27_2.0.1-5ubuntu5_i386.deb'. dpkg-deb: building package 'liblrmd28' in '../liblrmd28_2.0.1-5ubuntu5_i386.deb'. dpkg-deb: building package 'libcrmcommon34' in '../libcrmcommon34_2.0.1-5ubuntu5_i386.deb'. dpkg-deb: building package 'libstonithd26' in '../libstonithd26_2.0.1-5ubuntu5_i386.deb'. dpkg-deb: building package 'pacemaker-cli-utils' in '../pacemaker-cli-utils_2.0.1-5ubuntu5_i386.deb'. Since it doesn't build pacemaker-doc it does not depend on missing packages in i386 (pelican, for example). -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1863437 Title: [focal] pacemaker i386 should drop a few i386 only packages Status in pacemaker package in Ubuntu: In Progress Status in pacemaker source package in Focal: In Progress Bug description: When executing pacemaker i386 autopkgtests I realized that package "resource-agents" wasn't available for i386. When discussing this with @vorlon we came into the conclusion that some i386 only cluster packages could be removed from the repository, towards the effort of having *only the essential* packages available in i386 (to be run together with an amd64 host). IRC log: """ resource-agents i386 binary package the pacemaker binary is /not/ present on i386 in the release pocket that may have been an overly aggressive removal vorlon: are u keeping pacemaker because of dependencies ? yeah, I removed it when I shouldn't have (https://launchpad.net/ubuntu/focal/i386/pacemaker) rafaeldtinoco: pacemaker-dev is a build-dep of something else we need, see the referenced germinate output for full details https://people.canonical.com/~ubuntu-archive/germinate- output/i386.focal/i386+build-depends pacemaker-dev is a build-dep of dlm and libesmtp-dev is a build-dep of pacemaker, not the other way around (and dlm is a build-dep of lvm2) ah gotcha dlm -> corosync -> pacemaker so, even though I removed the binary in error from the release pocket, the right answer is still for pacemaker/i386 binary to go away (leaving only the -dev and lib packages) do you want me to fix that up, or do you want to? to fix that we should do like we did to samba ? yeah looks like the binaries you'll need to drop are pacemaker, pacemaker-cli-utils, pacemaker-remote and I'll remove those from -proposed right now, so that those don't hold up migration but I'll hold off on adding the hint until they're dropped from the source deal, and next hint ill do with proper branch """ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1863437/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1863437] Re: [focal] pacemaker i386 should drop a few i386 only packages
# i386 build in local environment dpkg-deb: building package 'libcib27' in '../libcib27_2.0.1-5ubuntu5_i386.deb'. dpkg-deb: building package 'pacemaker-common' in '../pacemaker-common_2.0.1-5ubuntu5_all.deb'. dpkg-deb: building package 'libcrmcommon34' in '../libcrmcommon34_2.0.1-5ubuntu5_i386.deb'. dpkg-deb: building package 'liblrmd28' in '../liblrmd28_2.0.1-5ubuntu5_i386.deb'. dpkg-deb: building package 'libpe-status28' in '../libpe-status28_2.0.1-5ubuntu5_i386.deb'. dpkg-deb: building package 'libcrmservice-dev' in '../libcrmservice-dev_2.0.1-5ubuntu5_all.deb'. dpkg-deb: building package 'pacemaker-dev' in '../pacemaker-dev_2.0.1-5ubuntu5_i386.deb'. dpkg-deb: building package 'libstonithd26' in '../libstonithd26_2.0.1-5ubuntu5_i386.deb'. dpkg-deb: building package 'libpengine-dev' in '../libpengine-dev_2.0.1-5ubuntu5_all.deb'. dpkg-deb: building package 'libcrmcluster-dev' in '../libcrmcluster-dev_2.0.1-5ubuntu5_all.deb'. dpkg-deb: building package 'libstonithd-dev' in '../libstonithd-dev_2.0.1-5ubuntu5_all.deb'. dpkg-deb: building package 'liblrmd-dev' in '../liblrmd-dev_2.0.1-5ubuntu5_all.deb'. dpkg-deb: building package 'libcrmcommon-dev' in '../libcrmcommon-dev_2.0.1-5ubuntu5_all.deb'. dpkg-deb: building package 'libtransitioner25' in '../libtransitioner25_2.0.1-5ubuntu5_i386.deb'. dpkg-deb: building package 'libpe-rules26' in '../libpe-rules26_2.0.1-5ubuntu5_i386.deb'. dpkg-deb: building package 'libcrmcluster29' in '../libcrmcluster29_2.0.1-5ubuntu5_i386.deb'. dpkg-deb: building package 'libcib-dev' in '../libcib-dev_2.0.1-5ubuntu5_all.deb'. dpkg-deb: building package 'pacemaker-resource-agents' in '../pacemaker-resource-agents_2.0.1-5ubuntu5_all.deb' dpkg-deb: building package 'libpengine27' in '../libpengine27_2.0.1-5ubuntu5_i386.deb'. dpkg-deb: building package 'libcrmservice28' in '../libcrmservice28_2.0.1-5ubuntu5_i386.deb'. dpkg-genbuildinfo --build=binary dpkg-genchanges --build=binary >../pacemaker_2.0.1-5ubuntu5_i386.changes dpkg-genchanges: warning: package pacemaker in control file but not in files list dpkg-genchanges: warning: package pacemaker-cli-utils in control file but not in files list dpkg-genchanges: warning: package pacemaker-remote in control file but not in files list dpkg-genchanges: info: binary-only upload (no source code included) I had to remove i386 architecture from pacemaker-doc as well, in order not to Build-Depend-Indep: on asciidoc, doxygen, graphviz, inkscape and publican. Build-Depends-Indep: asciidoc [amd64 arm64 armel armhf mips64el mipsel ppc64el ppc64 s390x x32], doxygen [amd64 arm64 armel armhf mips64el mipsel ppc64el ppc64 s390x x32], graphviz [amd64 arm64 armel armhf mips64el mipsel ppc64el ppc64 s390x x32], inkscape [amd64 arm64 armel armhf mips64el mipsel ppc64el ppc64 s390x x32], publican [amd64 arm64 armel armhf mips64el mipsel ppc64el ppc64 s390x x32], The other packages I removed with the option: dh -Nx # Ubuntu i386 binary compatibility only effort: Disable ceph support ifeq ($(shell dpkg-vendor --is Ubuntu && echo yes) $(DEB_HOST_ARCH), yes i386) BUILD_PACKAGES += \ -Npacemaker \ -Npacemaker-cli-utils \ -Npacemaker-remote endif -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1863437 Title: [focal] pacemaker i386 should drop a few i386 only packages Status in pacemaker package in Ubuntu: In Progress Status in pacemaker source package in Focal: In Progress Bug description: When executing pacemaker i386 autopkgtests I realized that package "resource-agents" wasn't available for i386. When discussing this with @vorlon we came into the conclusion that some i386 only cluster packages could be removed from the repository, towards the effort of having *only the essential* packages available in i386 (to be run together with an amd64 host). IRC log: """ resource-agents i386 binary package the pacemaker binary is /not/ present on i386 in the release pocket that may have been an overly aggressive removal vorlon: are u keeping pacemaker because of dependencies ? yeah, I removed it when I shouldn't have (https://launchpad.net/ubuntu/focal/i386/pacemaker) rafaeldtinoco: pacemaker-dev is a build-dep of something else we need, see the referenced germinate output for full details https://people.canonical.com/~ubuntu-archive/germinate- output/i386.focal/i386+build-depends pacemaker-dev is a build-dep of dlm and libesmtp-dev is a build-dep of pacemaker, not the other way around (and dlm is a build-dep of lvm2) ah gotcha dlm -> corosync -> pacemaker so, even though I removed the binary in error from the release pocket, the right answer is still for pacemaker/i386 binary to go away (leaving only the -dev and lib packages) do you want me to fix that up, or do you want to? to fix that we
[Ubuntu-ha] [Bug 1863437] [NEW] [focal] pacemaker i386 should drop a few i386 only packages
Public bug reported: When executing pacemaker i386 autopkgtests I realized that package "resource-agents" wasn't available for i386. When discussing this with @vorlon we came into the conclusion that some i386 only cluster packages could be removed from the repository, towards the effort of having *only the essential* packages available in i386 (to be run together with an amd64 host). IRC log: """ resource-agents i386 binary package the pacemaker binary is /not/ present on i386 in the release pocket that may have been an overly aggressive removal vorlon: are u keeping pacemaker because of dependencies ? yeah, I removed it when I shouldn't have (https://launchpad.net/ubuntu/focal/i386/pacemaker) rafaeldtinoco: pacemaker-dev is a build-dep of something else we need, see the referenced germinate output for full details https://people.canonical.com/~ubuntu-archive/germinate- output/i386.focal/i386+build-depends pacemaker-dev is a build-dep of dlm and libesmtp-dev is a build-dep of pacemaker, not the other way around (and dlm is a build-dep of lvm2) ah gotcha dlm -> corosync -> pacemaker so, even though I removed the binary in error from the release pocket, the right answer is still for pacemaker/i386 binary to go away (leaving only the -dev and lib packages) do you want me to fix that up, or do you want to? to fix that we should do like we did to samba ? yeah looks like the binaries you'll need to drop are pacemaker, pacemaker-cli-utils, pacemaker-remote and I'll remove those from -proposed right now, so that those don't hold up migration but I'll hold off on adding the hint until they're dropped from the source deal, and next hint ill do with proper branch """ ** Affects: pacemaker (Ubuntu) Importance: Medium Assignee: Rafael David Tinoco (rafaeldtinoco) Status: In Progress ** Affects: pacemaker (Ubuntu Focal) Importance: Medium Assignee: Rafael David Tinoco (rafaeldtinoco) Status: In Progress ** Changed in: pacemaker (Ubuntu) Status: New => In Progress ** Changed in: pacemaker (Ubuntu) Importance: Undecided => Medium ** Changed in: pacemaker (Ubuntu) Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco) ** Description changed: + When executing pacemaker i386 autopkgtests I realized that package + "resource-agents" wasn't available for i386. When discussing this with + @vorlon we came into the conclusion that some i386 only cluster packages + could be removed from the repository, towards the effort of having *only + the essential* packages available in i386 (to be run together with an + amd64 host). - When executing pacemaker i386 autopkgtests I realized that package "resource-agents" wasn't available for i386. When discussing this with @vorlon we came into the conclusion that some i386 only cluster packages could be removed from the repository, towards the effort of having *only the essential* packages available in i386 (to be run together with an amd64 host). + IRC log: + """ resource-agents i386 binary package the pacemaker binary is /not/ present on i386 in the release pocket that may have been an overly aggressive removal vorlon: are u keeping pacemaker because of dependencies ? yeah, I removed it when I shouldn't have (https://launchpad.net/ubuntu/focal/i386/pacemaker) rafaeldtinoco: pacemaker-dev is a build-dep of something else we need, see the referenced germinate output for full details - - https://people.canonical.com/~ubuntu-archive/germinate-output/i386.focal/i386+build-depends - + https://people.canonical.com/~ubuntu-archive/germinate- + output/i386.focal/i386+build-depends pacemaker-dev is a build-dep of dlm and libesmtp-dev is a build-dep of pacemaker, not the other way around (and dlm is a build-dep of lvm2) ah gotcha dlm -> corosync -> pacemaker so, even though I removed the binary in error from the release pocket, the right answer is still for pacemaker/i386 binary to go away (leaving only the -dev and lib packages) do you want me to fix that up, or do you want to? to fix that we should do like we did to samba ? yeah looks like the binaries you'll need to drop are pacemaker, pacemaker-cli-utils, pacemaker-remote and I'll remove those from -proposed right now, so that those don't hold up migration but I'll hold off on adding the hint until they're dropped from the source deal, and next hint ill do with proper branch + """ ** Also affects: pacemaker (Ubuntu Focal) Importance: Medium Assignee: Rafael David Tinoco (rafaeldtinoco) Status: In Progress -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1863437 Title: [focal] pacemaker i386 should
