I had a closer look how systemd emulates the old runlevels. systemd-
update-utmp-runlevel.service runs after graphical.target, multi-
user.target etc. started (After=runlevel1.target runlevel2.target
runlevel3.target runlevel4.target runlevel5.target, those are activated
in multi-user.target etc.). src/update-utmp/update-utmp.c determines
which runlevel to report in get_current_runlevel() using this table:
static const struct {
const int runlevel;
const char *special;
} table[] = {
/* The first target of this list that is active or has
* a job scheduled wins. We prefer runlevels 5 and 3
* here over the others, since these are the main
* runlevels used on Fedora. It might make sense to
* change the order on some distributions. */
{ '5', SPECIAL_GRAPHICAL_TARGET },
{ '3', SPECIAL_MULTI_USER_TARGET },
{ '1', SPECIAL_RESCUE_TARGET },
But targets only have states "dead" and "active", unlike units there is
no "activating". So we cannot use this approach to see if multi-
user.target *will* be active (or not) at some point in the future if we
just made it past basic.target. So fixing this in systemd itself will
require larger architectural changes which we presumably don't want in
an SRU (and maybe also don't want at all, as sysvinit and its runlevel
concept haven't mapped well to parallel/dynamic init systems such as
upstart or systemd).
Therefore I'd rather fix this in invoke-rc.d -- use runlevel only for
SysVinit, and drop the whole runlevel and /etc/rc?.d/ parsing stuff
under systemctl and just use "systemctl is-enabled" to determine whether
to start a service or not. That avoids the guesswork on both sides, is
structurally much simpler, and more robust.
** Changed in: systemd (Ubuntu)
Status: Triaged => Won't Fix
** Changed in: systemd (Ubuntu)
Assignee: Martin Pitt (pitti) => (unassigned)
** Changed in: init-system-helpers (Ubuntu)
Importance: Low => High
** Changed in: init-system-helpers (Ubuntu)
Status: Confirmed => In Progress
** Changed in: init-system-helpers (Ubuntu)
Assignee: (unassigned) => Martin Pitt (pitti)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1575572
Title:
apache2 fails to start if installed via cloud config (on Xenial)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1575572/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
