Supervisor not enabled or started in Ubuntu 16.04 after installation
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| supervisor (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
| Xenial |
Fix Released
|
Undecided
|
Nish Aravamudan | ||
| Yakkety |
Fix Released
|
Undecided
|
Unassigned | ||
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@
Ubuntu 16.04 LTS
peter@
supervisor:
Installed: 3.2.0-2
Candidate: 3.2.0-2
Version table:
*** 3.2.0-2 500
500 http://
500 http://
100 /var/lib/
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@
#!/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.
update-rc.d supervisor defaults >/dev/null
fi
if [ -x "/etc/init.
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:/
Here's an unhappy user wondering how to restore expected behavior:
http://
| information type: | Public → Public Security |
| information type: | Public Security → Public |
| Launchpad Janitor (janitor) wrote | #1 |
| Changed in supervisor (Ubuntu): | |
| status: | New → Confirmed |
| Changed in supervisor (Ubuntu): | |
| importance: | Undecided → Medium |
| Aditya (code-aditya) wrote | #2 |
| Alexis de Lattre (alexis-via) wrote | #3 |
| Ken S (kas130771) wrote | #4 |
| Miha Vrhovnik (mvrhov) wrote | #5 |
| Craig Kelly (craig-n-kelly) wrote | #6 |
| Cesc Fran (fran325) wrote | #7 |
| Chester (cd-pobox) wrote | #8 |
| Orestis Ioannou (orestis-8) wrote | #9 |
| Peter Odding (peterodding) wrote | #10 |
| Peter Odding (peterodding) wrote | #11 |
| Nish Aravamudan (nacc) wrote | #12 |
| Nish Aravamudan (nacc) wrote | #13 |
| Orestis Ioannou (orestis-8) wrote | #14 |
| Zach Welch (zwelch) wrote | #15 |
| Alex Gleason (alexgleason) wrote | #16 |
| Aditya (code-aditya) wrote | #17 |
| Changed in supervisor (Ubuntu): | |
| status: | Confirmed → Fix Released |
| Changed in supervisor (Ubuntu Yakkety): | |
| status: | New → Fix Released |
| Changed in supervisor (Ubuntu Xenial): | |
| status: | New → In Progress |
| assignee: | nobody → Nish Aravamudan (nacc) |
| Nish Aravamudan (nacc) wrote | #18 |
| Peter Odding (peterodding) wrote | #20 |
| description: | updated |
| Nish Aravamudan (nacc) wrote | #21 |
| Peter Odding (peterodding) wrote | #22 |
| Peter Odding (peterodding) wrote | #23 |
| Peter Odding (peterodding) wrote | #24 |
| Nish Aravamudan (nacc) wrote | #25 |
| Peter Odding (peterodding) wrote | #26 |
| Nish Aravamudan (nacc) wrote | #27 |
| Brian Murray (brian-murray) wrote Please test proposed package | #28 |
| Changed in supervisor (Ubuntu Xenial): | |
| status: | In Progress → Fix Committed |
| tags: | added: verification-needed |
| Kyle Mulka (km-pg) wrote | #29 |
| Peter Odding (peterodding) wrote | #30 |
| tags: |
added: verification-done removed: verification-needed |
| Launchpad Janitor (janitor) wrote | #31 |
| Changed in supervisor (Ubuntu Xenial): | |
| status: | Fix Committed → Fix Released |
| Brian Murray (brian-murray) wrote Update Released | #32 |
| Peter Odding (peterodding) wrote | #33 |
Status changed to 'Confirmed' because the bug affects multiple users.