Steve Langasek [2015-09-01 21:38 -0000]:
> The *only* thing that's made a no-op is the invocation of the init
> script *by the rc?.d symlink*. This is something that should never
> happen anyway; our dependency-based boot is already supposed to bypass
> invoking this script in favor of the upstart job. Any system that has
> been configured to not use the dependency-based boot in trusty is going
> to have race conditions at boot because of the combination of upstart
> job and init script
Thus in trusty you don't have the option to use dependency-based
sysvinit scripts, you *have* to have rc?.d symlinks; and they are
being used through upstart too via /etc/init/rc.conf.
So this change does influence the boot significantly, and I'm
not yet convinced that it necessarily regression proof? Or am I still
missing something?
Steve Langasek [2015-09-01 21:38 -0000]:
> The *only* thing that's made a no-op is the invocation of the init
> script *by the rc?.d symlink*. This is something that should never
> happen anyway; our dependency-based boot is already supposed to bypass
> invoking this script in favor of the upstart job. Any system that has
> been configured to not use the dependency-based boot in trusty is going
> to have race conditions at boot because of the combination of upstart
> job and init script
I suppose you are talking about insserv here. Note that trusty did /launchpad. net/ubuntu/ +source/ sysvinit/ 2.88dsf- 41ubuntu13) and
*not* use that yet, it was enabled in utopic
(https:/
it took a lot of fine-tuning and fixing to mop up the fallout.
Thus in trusty you don't have the option to use dependency-based
sysvinit scripts, you *have* to have rc?.d symlinks; and they are
being used through upstart too via /etc/init/rc.conf.
So this change does influence the boot significantly, and I'm
not yet convinced that it necessarily regression proof? Or am I still
missing something?