Charm fix was released in the 21.01 release with this patch
https://review.opendev.org/c/openstack/charm-hacluster/+/763077
** Changed in: charm-hacluster
Milestone: None => 21.01
** Changed in: charm-hacluster
Status: In Progress => Fix Released
--
You received this bug notification
Hello,
I cannot share sos report due to sensitive information. Symptoms are following.
Update of pacemaker in Ubuntu 16 to pacemaker 1.9 will cause crash of VMs. Also
error log of pacemaker and syslog are flooded by thousands of messages per
second - the disk will go out quit quickly.
Reboot -f
@Martin - hi, given the state of the bug it isn't considered an issue
/fixable-bug in pacemaker and a fix will be deployed via the charms
controlling it in this case.
I must admit I don't know enough about your particular case, but is it really
the very same one?
Would it make sense to report a n
Hi, when we can expect pacemaker1.10 version? I am working for company
developing and delivering cloud software and upgrade pacemaker to version 1.9
is causing crash of VMs. Problem is occurring very frequently (8-9 times from
10).
Our temporary solution is that we have blacklisted pacemaker 1.
Fix proposed to branch: master
Review: https://review.opendev.org/763077
** Changed in: charm-hacluster
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1903745
T
Based on discussion with Trent, who has access to more logs and data
than I currently do for this, all signs are indeed pointing to the
override timeouts provided by the charm itself.
A viable work-around to prevent this is to tweak the
service_stop_timeout config on the hacluster charm to be high
For clarity my findings so far are that:
- The package upgrade stops pacemaker
- After 30 seconds (customised down from 30min by charm-hacluster), the
stop times out and pretends to have finished, but leaves pacemaker
running (due to SendSIGKILL=no in the .service intentionally set
upstream to p
With regards to Billy's Comment #18, my analysis for that bionic
sosreport is in Comment #8 where I found that specific sosreport didn't
experience this issue - but I found most likely that node was suffering
from the issue occuring on the MySQL nodes it was connected to - and the
service couldn't
I should note that one of the reasons I do not suspect the charm is at
fault here is that in the bionic sosreport linked in the bug, I do not
see the delay that I would expect in a timeout scenario. If the stop
timeout were coming into play, I would expect to see a long duration on
the restart.
Ho
I'm not sure why the pacemaker task was marked as invalid. The issues
that Trent identified in comment #15 are a problem, but I'm not entirely
convinced that its *the* problem that was encountered here (as also
evidenced by Pedro in comment #16).
While packages do typically restart services automa
I have an environment with the same behavior in a Bionic VM that does
not use charm.
Preparing to unpack .../pacemaker_1.1.18-0ubuntu1.3_amd64.deb ...
Unpacking pacemaker (1.1.18-0ubuntu1.3) over (1.1.18-0ubuntu1.1) ...
Log ended: 2020-11-11 06:54:05
After the upgrade, there was an IP(master/vip
11 matches
Mail list logo
