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 there. HTH, Robie
signature.asc
Description: PGP signature
-- ubuntu-server mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
