| 2016-06-21 09:34:57 |
Peter Odding |
bug |
|
|
added bug |
| 2016-06-21 10:10:38 |
Peter Odding |
information type |
Public |
Public Security |
|
| 2016-06-21 10:10:42 |
Peter Odding |
information type |
Public Security |
Public |
|
| 2016-06-21 10:12:24 |
Launchpad Janitor |
supervisor (Ubuntu): status |
New |
Confirmed |
|
| 2016-06-21 17:33:22 |
Stephen Gornick |
bug |
|
|
added subscriber Stephen Gornick |
| 2016-06-24 21:31:56 |
Alberto Salvia Novella |
supervisor (Ubuntu): importance |
Undecided |
Medium |
|
| 2016-07-01 11:13:14 |
Peter |
bug |
|
|
added subscriber Peter |
| 2016-07-23 16:13:53 |
Aditya |
bug |
|
|
added subscriber Aditya |
| 2016-07-27 01:15:19 |
Robert Smith |
bug |
|
|
added subscriber Robert Smith |
| 2016-08-03 07:47:10 |
Lorenzo Battistini |
bug |
|
|
added subscriber Lorenzo Battistini - Agile BG |
| 2016-08-10 22:00:03 |
Craig Kelly |
bug |
|
|
added subscriber Craig Kelly |
| 2016-09-07 21:16:03 |
Peter Odding |
bug watch added |
|
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827729 |
|
| 2016-09-07 22:41:02 |
Nish Aravamudan |
bug |
|
|
added subscriber Nish Aravamudan |
| 2016-10-31 14:25:30 |
Ian Glover |
bug |
|
|
added subscriber Ian Glover |
| 2017-03-10 18:03:17 |
Nish Aravamudan |
supervisor (Ubuntu): status |
Confirmed |
Fix Released |
|
| 2017-03-10 18:03:23 |
Nish Aravamudan |
nominated for series |
|
Ubuntu Yakkety |
|
| 2017-03-10 18:03:23 |
Nish Aravamudan |
bug task added |
|
supervisor (Ubuntu Yakkety) |
|
| 2017-03-10 18:03:23 |
Nish Aravamudan |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-03-10 18:03:23 |
Nish Aravamudan |
bug task added |
|
supervisor (Ubuntu Xenial) |
|
| 2017-03-10 18:03:34 |
Nish Aravamudan |
supervisor (Ubuntu Yakkety): status |
New |
Fix Released |
|
| 2017-03-10 18:05:12 |
Nish Aravamudan |
supervisor (Ubuntu Xenial): status |
New |
In Progress |
|
| 2017-03-10 18:05:14 |
Nish Aravamudan |
supervisor (Ubuntu Xenial): assignee |
|
Nish Aravamudan (nacc) |
|
| 2017-03-13 21:28:02 |
Peter Odding |
description |
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.06, 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 |
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 |
|
| 2017-03-13 21:57:20 |
Nish Aravamudan |
description |
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 |
[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 |
|
| 2017-03-16 18:21:01 |
Brian Murray |
supervisor (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2017-03-16 18:21:05 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-03-16 18:21:07 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2017-03-16 18:21:15 |
Brian Murray |
tags |
supervisor systemd xenial |
supervisor systemd verification-needed xenial |
|
| 2017-03-16 20:28:21 |
Kyle Mulka |
bug |
|
|
added subscriber Kyle Mulka |
| 2017-03-20 20:58:22 |
Peter Odding |
tags |
supervisor systemd verification-needed xenial |
supervisor systemd verification-done xenial |
|
| 2017-03-23 17:05:16 |
Sam Cheng |
bug |
|
|
added subscriber Sam Cheng |
| 2017-03-23 22:04:55 |
Launchpad Janitor |
supervisor (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2017-03-23 22:04:59 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
