> The reason this is being done as a debconf question is because neither
option is good. And *since* we are forced to ask the user to pick their
poison, I consider it insufficient to ask this question only once. The
question should by default be re-asked, at each package upgrade, so that
the user has an opportunity to make the decision that is correct for
them at that moment.

> In addition, the current default for the debconf question is "true";
so by default, which includes on non-interactive upgrades (unattended
upgrades or the like), the behavior the user gets here is that the
service is restarted, stopping any un-supervised containers. If the
docker.io package is not able to detect whether all running containers
will be automatically restarted, then if this is to be a supported use
case at all, the default should be to not restart: because it is less
disruptive to have the docker service become unavailable, than to have
the docker containers become unavailable.

Fair enough, will update Git and poke Michael when it's ready (thanks
for noting the exact pattern we ought to be using to accomplish this).

> "reconfigure" is not a valid argument to a postinst script. (And dpkg-
reconfigure does not invoke it this way - it invokes it as 'postinst
configure'.) So the first part of this test is always true and can be

I included that because I read on the lists that it was intended to be
supported _eventually_, but I guess that was long enough ago (and the
transition wouldn't be fun to implement across the archive) that it's
probably safe to ignore that ever happened; fair enough. O:)

> And the check for status is not consistent with expected behavior of
packages: upgrading the package should normally start the service even
if it was currently not running, unless the administrator has explicitly
disabled it through policy-rc.d.

So, this block of code is _only_ responsible for performing the daemon
restart, hence why this bit was included.  Starting the daemon happens
in the following block.

To put it another way, if Docker isn't running, there's not really a
good reason to even prompt the user whether we're OK to restart it -- we
should just fire it up.

Would it make more sense to have this block just stop the daemon instead
and let the following block start it up?

> This code includes a check for "$shouldStartRestart"; but this is the
code to start the daemon on package initial installation, and the
debconf question doesn't ask about starting, only about restarting. So I
think this check shouldn't be there.

The "$shouldStartRestart" variable basically amounts to "Are we running
this script because of package install or because of 'dpkg-
reconfigure'?" -- if the user is simply running "dpkg-reconfigure", I
don't think it's appropriate or necessary for us to fire up the Docker
daemon (or bother restarting it -- we only care about doing that when
upgrading or installing the package).

Since we're going to ditch the check for `[ "$1" != 'reconfigure' ]`, we
can just use "$DEBCONF_RECONFIGURE" which will make this more clear.

So to summarize, the current code, as written, will restart the daemon
based on the user's input, but only during package install/upgrade (not
during "dpkg-reconfigure"), and if the daemon isn't running, will start
it up during package install/upgrade (also not during "dpkg-

You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

  upgrade to 17.03.2-ce in 16.04+

To manage notifications about this bug go to:

ubuntu-bugs mailing list

Reply via email to