** Changed in: corosync (Ubuntu)
Status: Triaged => In Progress
** Summary changed:
- corosync fails to start in container (armhf) bump some limits
+ corosync fails to start in unprivileged containers - autopkgtest failure
--
You received this bug notification because you are a member
Reopening per my preceding comment
** Changed in: corosync (Ubuntu)
Status: Invalid => Triaged
** Changed in: corosync-qdevice (Ubuntu)
Status: Invalid => Triaged
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed
** Changed in: corosync (Ubuntu)
Status: In Progress => Invalid
** Changed in: corosync-qdevice (Ubuntu)
Status: In Progress => Invalid
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed to corosync in Ubuntu.
On Sun, Jul 21, 2019 at 04:24:08AM -, Rafael David Tinoco wrote:
> Somehow the lxd containers being used for autopkgtest are, likely,
> different. x64 seems to be running privileged containers for need_root
> tests, while armhf is not (orelse x64 selfpkgtests wouldn't pass either,
> like
Somehow the lxd containers being used for autopkgtest are, likely,
different. x64 seems to be running privileged containers for need_root
tests, while armhf is not (orelse x64 selfpkgtests wouldn't pass either,
like demonstrated in previous comment).
I'll suggest a hints-ubuntu test marking this
corosync-qdevice autopkgtest is also failing because of the same reason
(armhf architecture).
--
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
## unprivileged x64:
root@corosync:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu Eoan Ermine (development branch)
Release:19.10
Codename: eoan
root@corosync:~# uname -a
Linux corosync 5.0.0-21-generic #22-Ubuntu SMP Tue Jul 2 13:27:33
This "bug" happens because of "unprivileged" containers:
root@corosync:~# corosync -f
Jul 20 21:26:32 notice [MAIN ] Corosync Cluster Engine 3.0.1 starting up
Jul 20 21:26:32 info[MAIN ] Corosync built-in features: dbus monitoring
watchdog augeas systemd xmlconf snmp pierelro bindnow
Jul
Thanks Robie, and I totally agree. I'll give a fast look in lxd cases
and comment back here so we can take a decision.
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed to pacemaker in Ubuntu.
Note that if this turns out to be challenging a "force-badtest" is
likely to be acceptable to get the package migrated for now.
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed to pacemaker in Ubuntu.
Quick clarifications on next steps:
- corosync runs as root... so its unclear to me it would fail for
prlimit64() inside a container if sys_resource is denied. for sure
prlimit64() fails in 2 conditions: not root and no "cap_sys_resource" is
configured for the binary (CAP_SYS_RESOURCE=+ep), which
Hello Dimitri,
I tried to reproduce the same behaviour using default LXC containers in
real HW (ARMv8 - ARMHF containers) and wasn't able to.
Nevertheless, I was able to cause corosync not to start due to failed
mlock() calls:
main.log:Jul 15 18:27:57 [2386] hasid01 corosync warning [MAIN ]
I flagged this as high as this is impacting pacemaker migration. After
this being fixed, corosync (depending on libknet1 will still block
migration, but thas has already been address in MIR
https://bugs.launchpad.net/ubuntu/+source/kronosnet/+bug/1811139).
I'm working on this now.
** Changed in:
I assigned to myself to address comment #1 from Robie and try to bump
needed values from the test itself. I'll test in an armhf environment
just to make sure its good. This will unblock:
https://people.canonical.com/~ubuntu-archive/proposed-
migration/update_excuses_by_team.html#ubuntu-server
** Changed in: corosync (Ubuntu)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Changed in: pacemaker (Ubuntu)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Tags removed: ubuntu-ha
--
You received this bug notification because you are a member of
** Tags added: ubuntu-ha
** Changed in: corosync (Ubuntu)
Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco)
** Changed in: pacemaker (Ubuntu)
Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco)
--
You received this bug notification because you are a member of
Am I right in thinking that the limits being too low are causing false
positives in autopkgtests?
If so, we could check the limits in the test themselves and skip (exit
77 and declare "skippable") if on armhf and the limits aren't high
enough. That's a reasonable action for the packages, I think.
17 matches
Mail list logo
