** No longer affects: maas/1.4 -- 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 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp