<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 3, 2020 at 6:49 PM Bryce Harrington <<a href="mailto:bryce.harrington@canonical.com">bryce.harrington@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The question is are there any scenarios where<br>
we care about this legacy init system?  If there is, then we may need<br>
further logic beyond what I've included; if there isn't, then can we<br>
omit the update-rc.d / invoke-rc.d logic entirely?<br></blockquote><div><br></div><div>It looks like we're just talking about bionic+ aren't we?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Sergio demoed to me what he and Paride discovered while examining<br>
<a href="http://docker.io" rel="noreferrer" target="_blank">docker.io</a>'s prerm file (/var/lib/dpkg/info/<a href="http://docker.io" target="_blank">docker.io</a>.prerm).  Debhelper<br>
automatically adds a command to stop the docker service<br>
unconditionally:<br>
<br>
    # Automatically added by dh_systemd_start/13.2.1ubuntu1<br>
    if [ -d /run/systemd/system ]; then<br>
            deb-systemd-invoke stop 'docker.service' 'docker.socket' >/dev/null || true<br>
    fi<br>
    # End automatically added section<br>
<br>
This means three things.  1) Proposal A can be crossed off, 2) we might<br>
potentially be able to address the problem in <a href="http://docker.io" rel="noreferrer" target="_blank">docker.io</a>'s maintscripts<br>
better than in containerd's maintscripts by replacing this debhelper<br>
logic with some conditionals like done for Proposal X, and 3) since the<br>
user's installed <a href="http://docker.io" rel="noreferrer" target="_blank">docker.io</a>'s prerm gets run before any new package's<br>
maintscripts, this means all our proposals suffer the same problem that<br>
all of them will result in docker.service getting this 'stop' command at<br>
least one time.<br>
<br>
This third item I'm not sure how we're going to get around, or if we<br>
even can.  There was an idea expressed early on to introduce a new<br>
package with the simple purpose of hackily shimming out this<br>
`deb-systemd-invoke stop` call from docker's prerm before doing anything<br>
at all with the <a href="http://docker.io" rel="noreferrer" target="_blank">docker.io</a> or containerd packages.  Should we revisit<br>
this idea?  Or should we simply accept that we're going to trigger the<br>
bug for all users one more time in order to get the long term fix in<br>
place?<br></blockquote><div><br></div><div>Could this be done in the <a href="http://docker.io">docker.io</a> update. The idea being that it's the containerd package that's doing this and a <a href="http://docker.io">docker.io</a> update could do the shim work without the need of a 3rd package. This means that we have to rely on the time difference in the docker vs the containerd release change to do the best we can. </div><div><br></div></div></div>