touch-packages team mailing list archive
-
touch-packages team
-
Mailing list archive
-
Message #26762
[Bug 1251257] Re: [SRU] avahi fails in containers
MAAS trunk no longer includes Avahi, so closing this bug there.
** Changed in: maas
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
https://bugs.launchpad.net/bugs/1251257
Title:
[SRU] avahi fails in containers
Status in MAAS:
Fix Released
Status in MAAS 1.4 series:
Triaged
Status in “avahi” package in Ubuntu:
Fix Released
Status in “avahi” source package in Precise:
Fix Released
Status in “avahi” source package in Saucy:
Fix Released
Status in “avahi” source package in Trusty:
Fix Released
Bug description:
installed a brand new maas server on suacy into an lxc container from
archive and http://<ip>/MAAS is not accessible although http://<ip> is
accessible
http://<ip>/MAAS is getting logged to /var/log/apache2/access.log
though so request is making it through
<roaksoax> danwest: can you please pastebin apache2's error and access.log
<danwest> http://paste.ubuntu.com/6405411/
<danwest> http://paste.ubuntu.com/6405412/
<roaksoax> danwest: I know what it is
<roaksoax> danwest: dbus/avahi
<roaksoax> danwest: try to restart whatever avahi service there is
<andreas> "dbus" reminds me of https://bugs.launchpad.net/juju-core/+bug/1248283
<andreas> but that was about the units, not maas itself
<danwest> https://pastebin.canonical.com/100290/
<danwest> same problem
<roaksoax> danwest: yeah the avahi daemon is failing to start, causing maas to fail
<roaksoax> danwest: maybe restart whatever dbus serviice it is, and then the avahi-daemon
<matsubara> danwest, restart dbus and avahi-daemon, see https://bugs.launchpad.net/maas/+bug/1221059
<roaksoax> danwest: did avahi-daemon restart corrrectly?
<danwest> nope
<roaksoax> danwest: i guess then an issue with dbus is preventing avahi from working... hence maas failing
<danwest> roaksoax: should not matter but the only thing that is a little unique is that this is in a saucy container
<roaksoax> danwest: ah so then thats the issue...
<danwest> what, the container?
<roaksoax> yeah
<danwest> how so?
<roaksoax> avahi might have issues running in a container
<danwest> hallyn: roaksoax: what should I file that lxc/avahi /maas bug that I hit this morning against?
<hallyn> danwest: i think maas should work around it by unsetting rlimit-nproc
<hallyn> (and/or by running on trusty in a private user ns
<hallyn> smoser: fwiw the problem is that avahi sets its nproc rlimit to exaclty 3, but in a container it's using a uid that is in use on the host - so it exceeds 3 tasks
<hallyn> (i.e. it's reusing uid which is ntp on the host, and ntp is running; or just another avahi)
<smoser> ok...
<smoser> so that doesn't seem like maas's problem to me
<smoser> nor juju's really.
<hallyn> smoser: it is. it needs to pick a unique uid, or configure avahi to ignore the rlimit
<smoser> maas isn't running avahi
<smoser> is it ?
<hallyn> i duno what's actually running it :) it's *for* maas, but it probably is juju
<smoser> what if there was a bug in php, and a user used maas to deploy php.
<smoser> should we fix that in maas ?
<hallyn> you're talking about a bug. i'm talking about a resource conflict
<hallyn> having avahi alwasy run without nprocs, for protection, would be wrong for this.
fix is still up for debate on this one...
[Impact]
Avahi sets the rlimit_nproc to 3, causing avahi to fail running in containers. This This option should not be set in containers at all. This causes avahi-daemon to fail, hence all the applications that use avahi will also fail. In this particular case, MAAS fails because of this.
[Test Case]
1. Install a container.
2. Install MAAS
3. Check apache2 log for errors, such as those in [1].
[Regression Potential]
Minimal. This has been tested and works as expected.
[1]: http://paste.ubuntu.com/6405412/
To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1251257/+subscriptions