Hi Nish and thank you so much for backporting a fix to xenial! I can confirm that with the version of Supervisor in your PPA the original issue I reported is resolved, i.e. by the time 'apt install supervisor' returns, the Supervisor daemon has been started. Also both of the commands I mentioned in my opening post confirm the correct configuration:
peter@mbp> systemctl --quiet is-enabled supervisor && echo OK || echo ER OK peter@mbp> systemctl --quiet is-active supervisor && echo OK || echo ER OK Apart from this the Supervisor daemon seems to be working fine, as expected. ** Description changed: 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 + # 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:~$ 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 + 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 + 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 + # 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 + # 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 + 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 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1594740 Title: Supervisor not enabled or started in Ubuntu 16.04 after installation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/supervisor/+bug/1594740/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
