invoke-rc.d does not start services in containers

Bug #1587903 reported by Martin Pitt
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu Seeds
Fix Released
Undecided
Martin Pitt
init-system-helpers (Ubuntu)
Fix Released
Wishlist
Martin Pitt

Bug Description

In current yakkety, invoke-rc.d start is broken in containers:

$ lxc launch images:ubuntu/yakkety/amd64 y1
$ lxc exec y1 systemctl stop cron
$ lxc exec y1 invoke-rc.d cron start
$ lxc exec y1 systemctl status cron
● cron.service - Regular background program processing daemon
   Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Wed 2016-06-01 13:48:50 UTC; 9s ago

"invoke-rc.d cron stop" does seem to work, though. This is a regression in recent yakkety.

ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: init-system-helpers 1.34ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-23.41-generic 4.4.10
Uname: Linux 4.4.0-23-generic x86_64
ApportVersion: 2.20.1-0ubuntu4
Architecture: amd64
CurrentDesktop: i3
Date: Wed Jun 1 15:49:23 2016
EcryptfsInUse: Yes
PackageArchitecture: all
SourcePackage: init-system-helpers
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Martin Pitt (pitti) wrote :
Changed in init-system-helpers (Ubuntu Yakkety):
status: New → In Progress
importance: Undecided → Critical
assignee: nobody → Martin Pitt (pitti)
Revision history for this message
Martin Pitt (pitti) wrote :

Note that this does not affect VMs and real iron.

Revision history for this message
Martin Pitt (pitti) wrote :

This isn't really a regression as such, xenial's init-system-helpers does not work either. This is rather related to initscripts, sysv-rc etc. falling out of ubuntu-minimal, so invoke-rc.d somehow decides that the policy is to not run the script (RC==101).

Revision history for this message
Martin Pitt (pitti) wrote :

So this shows two issues:

 * We need to put sysv-rc back into required, as long as we still have packages which only ship init.d scripts, so that they get proper /etc/rc?.d/ links.

 * invoke-rc.d should stop looking at rc?.d links for systemd units, and rather check if *those* are enabled.

Revision history for this message
Martin Pitt (pitti) wrote :
Changed in init-system-helpers (Ubuntu Yakkety):
importance: Critical → Medium
Changed in ubuntu-seeds:
assignee: nobody → Martin Pitt (pitti)
status: New → In Progress
Changed in init-system-helpers (Ubuntu Yakkety):
importance: Medium → Wishlist
Changed in ubuntu-seeds:
status: In Progress → Fix Released
Revision history for this message
Martin Pitt (pitti) wrote :
no longer affects: init-system-helpers (Ubuntu Yakkety)
Changed in init-system-helpers (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package init-system-helpers - 1.35ubuntu1

---------------
init-system-helpers (1.35ubuntu1) yakkety; urgency=medium

  * Merge from Debian unstable. Remaining Ubuntu changes:
    - init: Drop sysvinit-core as alternative init system.

init-system-helpers (1.35) unstable; urgency=medium

  * invoke-rc.d: When running under systemd, query systemctl is-enabled
    instead of checking for rc?.d/ links. This allows operation without
    sysv-rc with packages that ship native systemd units. Packages which only
    ship an init.d script continue to need sysv-rc and runlevels, of course.
    (Closes: #827191, LP: #1587903)

 -- Martin Pitt <email address hidden> Sun, 19 Jun 2016 21:09:01 +0200

Changed in init-system-helpers (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.