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 *not* use that yet, it was enabled in utopic (https://launchpad.net/ubuntu/+source/sysvinit/2.88dsf-41ubuntu13) and 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? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1273462 Title: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1273462/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
