It is correct, in general, to check for /run/systemd/system to detect if systemd manages pid 1.
Imho deputy systemd (used by snapd, on trusty, with xenial-lts kernel) should not have been creating that, however I fear that without that directory snapd and snaps therein may get confused (in classic confinment). It is true that trusty only uses upstart as pid1 with no other options; and any system systemd jobs are inert (deputy systemd only looks for deputy things). Note that although xenial ships both upstart & systemd; only systemd is supported as pid1 on all form-factors. (upstart as pid1 is only supported on xenial ubuntu touch product, which is now end-of-life). Possibly we could create one more directory e.g. /run/dsystemd/system or some such, which maas can check for to destinguish "systemd or deputy- systemd". However, checking /sbin/init like done in the proposed merge proposal is very adequate for maas needs, and should yield correct results. As far as I can tell, since on xenial either upstart-sysv or systemd-sysv may provide /sbin/init, with systemd-sysv being the default everywhere. (upstart-sysv on xenial is for ubuntu touch only). Ideally, I do not want to touch deputy systemd uploads. -- 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
