containerd / LP: #1870514

Robie Basak robie.basak at
Fri Dec 4 16:59:19 UTC 2020

On Thu, Dec 03, 2020 at 03:47:53PM -0800, Bryce Harrington wrote:
> One other more philosophical design question you could help answer.  The
> debhelper generated stuff provided a chunk of code for handling service
> restart via invoke-rc.d.  The question is are there any scenarios where
> we care about this legacy init system?  If there is, then we may need
> further logic beyond what I've included; if there isn't, then can we
> omit the update-rc.d / invoke-rc.d logic entirely?

For Ubuntu, Xenial could be using upstart following a release upgrade
from Trusty, but apart from that, Ubuntu is "guaranteed" to be running
systemd since we don't support anything else. The only exception I can
think of is that application containers break when packages supply
tmpfiles.d since that never happens if nothing is there to start apply
tmpfiles.d. Anyway, my point is that the Sys V stuff only exists because
Debian still supports that and so we inherit the machinery for multiple
init systems even though in Ubuntu we don't support variance from
systemd. Therefore, I wouldn't consider it a regression to break a
system using not-systemd in a stable update in Ubuntu. We should
probably avoid regressing user entry points though (eg. if a user calls
a /etc/init.d script directly). Others' views may vary (if so, please
speak up).

So I don't think our maintainer scripts in a stable update need to
maintain support for dealing with the case that a machine actually
running Sys V init. I don't think what you suggest would break an
/etc/init.d entry point, but please check and if it does we can go from


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <>

More information about the ubuntu-server mailing list