group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <1594740@xxxxxxxxxxxxxxxxxx>]

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