On Wed, Dec 13, 2017 at 9:57 AM, Robie Basak <robie.basak@ubuntu.com> wrote:
1) Fix systemd on Trusty so that testing for /run/systemd/system works
again. This will probably need to remove /run/systemd/system correctly
on postinst as part of the fix. This will unbreak MAAS and snapd working
together.
2) Come up with and agree on some other universal way for testing for
systemd and make that work everywhere. Then we can SRU that test to MAAS
in Trusty, and fix any other packages in Trusty affected by the
behaviour change of the original test.
3) Accept that on Trusty the general case is now broken, and make the
official test be something like the following. This will need to be
SRU'd to MAAS in Trusty, and we'll need to fix any other packages in
Trusty affected by the behaviour change of the original test.
if Trusty: upstart
else if [ -d /run/systemd/system ]: systemd
else [existing checks for other init systems]
Are there any other options? Please discuss as you wish. My purpose in
starting this thread is to record consensus once we have it, so the
archive of this thread can be used to be consistent in how we handle
fixing this.
We discussed this from the MAAS angle recently, and one of the options the team came up with was to check what binary the `/proc/1/exe`link points to. Unfortunately, you can't do that without elevated privileges, but we could ship a simple setuid/setcap utility to do so. I've got a quick proof-of-concept here, if that's an option:
That said, MAAS 1.9 is intended to run on Trusty, and 2.0 through 2.3 are intended to run on Xenial. Due to other dependencies that changed between Trusty and Xenial, I don't think it would be practical to support MAAS on a "Frankenstein" Trusty system that has been upgraded to Xenial but not rebooted.
So that's somewhat a combination of (2) and (3). I think it's difficult to predict if the benefit of doing (1) is worth the effort.
Regards,
Mike
