group.of.nepali.translators team mailing list archive
-
group.of.nepali.translators team
-
Mailing list archive
-
Message #11992
[Bug 1594740] Re: Supervisor not enabled or started in Ubuntu 16.04 after installation
This bug was fixed in the package supervisor - 3.2.0-2ubuntu0.1
---------------
supervisor (3.2.0-2ubuntu0.1) xenial; urgency=medium
* Enable and start systemd service. Thanks to Orestis Ioannou
<orestis@xxxxxxxxxxxx>. (Closes LP: #1594740).
-- Nishanth Aravamudan <nish.aravamudan@xxxxxxxxxxxxx> Fri, 10 Mar
2017 10:43:23 -0800
** Changed in: supervisor (Ubuntu Xenial)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1594740
Title:
Supervisor not enabled or started in Ubuntu 16.04 after installation
Status in supervisor package in Ubuntu:
Fix Released
Status in supervisor source package in Xenial:
Fix Released
Status in supervisor source package in Yakkety:
Fix Released
Bug description:
[Impact]
* In all prior releases to 16.04, `apt-get install supervisor` would
result in supervisor being started after package installation (and
configured to start by default at boot). This is the principle of
least surprise in action and reflects Ubuntu's ease of use.
* Due to the timing of 16.04, the version from Debian was broken to
not support systemd properly.
* Both Debian and Ubuntu have been fixed since the version in 16.04,
in the same way as the proposed fix.
[Test Case]
* Install supervisor. After installation, the service should be
running and should be enabled.
[Regression Potential]
* As the behavior is currently regressed relative to 14.04, I believe
the primary potential source of regressions will be users who have
manually fixed-up systemd to do what was expected on their systems. I
believe dpkg will notice the differences, if any, between the system-
installed supervisor systemd files and those in this package.
---
Expected behavior
=================
In Ubuntu 10.04, 12.04 and 14.04 after running "apt-get install
supervisor" the Supervisor daemon is automatically enabled (to start
on boot) and started (so that Supervisor is running by the time apt-
get returns).
What actually happens
=====================
In Ubuntu 16.04 the Supervisor daemon is not automatically enabled nor
is it started during installation. This breaks compatibility with
previous and expected behavior.
Why this is a problem
=====================
I've built dozens of tools that use Supervisor for process supervision
and these tools are deployed using custom Debian packages. Each of
these packages has a dependency on the supervisor package with the
expectation that Supervisor will be installed, enabled and started so
that my post-installation scripts can call "supervisorctl" and expect
it to work (instead of complaining about a missing UNIX socket file
and exiting with a nonzero status code, thereby breaking my automated
server provisioning).
Known workaround
================
Create a shim package with a dependency on supervisor and a post-
installation script that runs the following commands:
# On Ubuntu 16.04 the installation of Supervisor does not
# enable and start the Supervisor daemon which breaks
# compatibility with previous Ubuntu releases.
if [ $(lsb_release --short --codename) = xenial ]; then
# Make sure the daemon is enabled.
if ! systemctl --quiet is-enabled supervisor; then
systemctl enable supervisor
fi
# Make sure the daemon is started.
if ! systemctl --quiet is-active supervisor; then
systemctl start supervisor
fi
fi
Alternatively one can obviously just run these commands by hand to
rectify the situation.
It's kind of nasty that I have to create a shim package like this to
compensate for a break in backwards compatibility that is -as far as I
know- undocumented and most likely unintentional. What's more is that
a lot of people will lack the means to create shim packages like this,
so thousands of Ubuntu users / integrators / system administrators
worldwide will need to repeat these shenanigans manually.
Affected versions
=================
peter@template-xenial:~$ lsb_release --short --description
Ubuntu 16.04 LTS
peter@template-xenial:~$ apt-cache policy supervisor
supervisor:
Installed: 3.2.0-2
Candidate: 3.2.0-2
Version table:
*** 3.2.0-2 500
500 http://mirror.nl.leaseweb.net/ubuntu xenial/universe amd64 Packages
500 http://mirror.nl.leaseweb.net/ubuntu xenial/universe i386 Packages
100 /var/lib/dpkg/status
Root cause analysis
===================
In Ubuntu 16.04 Supervisor is managed by systemd however the post-
installation script is using update-rc.d and invoke-rc.d to enable and
start Supervisor. As far as I know these commands are remnants of the
old daemon management infrastructure and they don't integrate with
systemd, hence the breakage:
peter@template-xenial:~$ cat /var/lib/dpkg/info/supervisor.postinst
#!/bin/sh
set -e
# Automatically added by dhpython:
if which pycompile >/dev/null 2>&1; then
pycompile -p supervisor
fi
# End automatically added section
# Automatically added by dh_installinit
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ]; then
if [ -x "/etc/init.d/supervisor" ]; then
update-rc.d supervisor defaults >/dev/null
fi
if [ -x "/etc/init.d/supervisor" ] || [ -e "/etc/init/supervisor.conf" ]; then
invoke-rc.d supervisor start || exit $?
fi
fi
# End automatically added section
Conclusion
==========
Is there a remote chance of getting this fixed in Ubuntu 16.04, maybe
in a later point release? On the one hand I get that fixing this now
is a big change compared to the original release of Ubuntu 16.04, on
the other hand I have found dozens of unsuspecting users (see below)
being bitten by this change in behavior and I haven't found a single
user who appreciated it :-).
If there is no chance of fixing this it should at least be documented
in the release notes as a known regression, because I haven't been
able to find any proper documentation about this change and I have
found dozens of people being bitten by the break in backwards
compatibility.
External references
===================
Some random reports of people running into (what I believe is) this
exact issue:
Here's an upstream bug report, where nothing can be fixed:
https://github.com/Supervisor/supervisor/issues/735
Here's an unhappy user wondering how to restore expected behavior:
http://unix.stackexchange.com/questions/281774/ubuntu-server-16-04-cannot-get-supervisor-to-start-automatically
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/supervisor/+bug/1594740/+subscriptions