Comment 4 for bug 1575572

> The problem seems to be that any package install during systemd boot of
> a package that only provides sysvinit scripts will fail. Reading invoke-rc.d,
> i'm not really sure why a proper systemd service woudlnt fail also.

The RUNLEVELHELPER check is buggy, yes. However, the behavior of invoke-rc.d is by design; if the runlevel can't be determined (which according to systemd it still would not be, even if the bug in invoke-rc.d was fixed), invoke-rc.d should default to doing nothing because there's no system policy to say whether the service should be started.

I think there's a case to be made that this is a bug in systemd, for returning 'unknown' for the runlevel in these cases. The historical behavior of sysvinit is that everything triggered from /etc/init.d/rc inherits the value of the current runlevel in the RUNLEVEL environment variable; and running e.g. 'RUNLEVEL=2 runlevel' - including on systemd - will report this env value as the target runlevel.

$ runlevel
N 5
$ PREVLEVEL=5 RUNLEVEL=2 runlevel
5 2
$

Unless cloud-init is being called so early in boot that the runlevel target is not known - which seems very unlikely - then I think the correct thing for systemd to do is to honor this historical behavior by making the 'runlevel' command return the target runlevel when called from a systemd unit that's run at boot, even if that target has not yet been reached. Opening a task on systemd for this.

Note, BTW, that the above also suggests a workaround for cloud-init to employ. If for whatever reason systemd will not set itself up to return the proper runlevel value, cloud-init can simply set RUNLEVEL=2 in the environment prior to calling dpkg, and invoke-rc.d will pick this up and DTRT with it.