I would accept a version of this SRU that hard-codes the choice of upstart as the init system on 14.04, because that is the only init system supported in that version of Ubuntu.
We can discuss further whether the deput-init systemd package in trusty needs further changes to not fall afoul of common init system detection techniques, but I don't think that should block fixing MAAS in this scenario. Currently, all the proposed methods of detecting the init system have corner cases where they break. Most of these corner cases are negligible for maas, however. The one option I know that doesn't have corner cases is to invoke '/sbin/initctl version' and check its return code. But I leave it up to the MAAS team whether to implement this vs. a lighter-weight check. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1732703 Title: MAAS does not detect properly if Ubuntu is using upstart/systemd Status in MAAS: Won't Fix Status in MAAS 1.9 series: In Progress Status in maas package in Ubuntu: New Status in snapd package in Ubuntu: Won't Fix Status in systemd package in Ubuntu: New Status in maas source package in Trusty: New Status in snapd source package in Trusty: New Status in systemd source package in Trusty: New Bug description: [impact] Since Trusty uses upstart by default, MAAS manages its services with upstart. However, when a user installs systemd (even if it is not used as the init system), MAAS detects systemd installed and tries to manage its services via systemd. This obviously creates issues and prevents MAAS from working. [Test Case] 1. Install & configure MAAS 2. Add machines 3. install systemd 4. MAAS will fail to manage machines [Regression potential] Minimal. This just ensures that upstart is detected correctly even if systemd is installed (but not used). [Original bug report] Trusty uses upstart by default, and installing snapd (e.g. for livepatch purposes), pulls systemd too. In this setup, upstart is _not_ replaced by systemd, but MAAS "detects" systemd as init because of the existence of /run/systemd/system: @src/provisioningserver/utils/__init__.py:505 SYSTEMD_RUN_PATH = '/run/systemd/system' def get_init_system(): """Returns 'upstart' or 'systemd'.""" if os.path.exists(SYSTEMD_RUN_PATH): return 'systemd' else: return 'upstart' One possible solution would be to check if /sbin/init is a symlink pointing to /lib/systemd/systemd: def get_init_system(): """Returns 'upstart' or 'systemd'.""" initpath = os.readlink("/sbin/init") if (initpath == "/lib/systemd/systemd"): return 'systemd' else: return 'upstart' Other affected parts of the code are the postinst files for maas-proxy and maas-dhcp (debian/maas-proxy.postinst debian/maas-dhcp.postinst), throwing an error if maas is installed after systemd in Trusty To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1732703/+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
