Excerpts from Dmitrijs Ledkovs's message of 2013-11-02 23:16:07 UTC: > At the moment we guarantee that networking & local filesystems will be > available when runlevel 2 (and similar) are emitted. > Apart from rename, what other benefits does this semantic sugar bring? >
First, job writers shouldn't need to be boot experts, so logically named state tracking jobs make more sense than runlevels. Second, this provides the ability to insert things into the stream rather than add more parallelized actions to "runlevel 2". Cron is a particular example where it is almost always better to start cron as late as possible. Consider this scenario: [mysql.conf] start on runlevel [2345] [cron.conf] start on runlevel [2345] In this scenario, mysql is starting up in parallel with cron. Cron is _much_ faster than mysql and so starts, and immediately runs its' @reboot jobs which include Optimizing MySQL tables. This fails because mysql is still coming up. Now: [mysql.conf] start on starting network-services [cron.conf] start on started network-services The ordering is achieved. cron is not started until mysql is started, but they didn't have to explicitly state the relationship between cron and mysql, it just makes logical sense. It just means being able to order things based on this mostly generic idea that most things are network services and thus would be migrated to use the network-services job. If that works out, we can also have other classes of jobs like security-services and login-services. Ideally we'd be able to hide all of the nitty gritty plumbing events in these jobs so that the general Upstart job reads more like a human thinks. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/701576 Title: Upstart should provide a generic network-services job for non-boot- critical network services to follow. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/701576/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
