Hello, On Mon, Jan 10, 2011 at 1:47 PM, Janne Karhunen <[email protected]> wrote: > On Sun, Jan 9, 2011 at 8:35 PM, Arjan van de Ven <[email protected]> > wrote: > >>> PS: initV support parallel start and depends (see in debian) >> >> the point of upstart isn't parallel start; that's almost the worst feature >> of upstart to be honest.... >> (but obviously I expect this to be done correctly and properly as part of >> the upstart transition) >> the point is the integration with the security framework. > > Right, and do we have things like multi-state support in systemd yet? > Preferably so that states could change without reboots smoothly. > Let alone the fact that upstart can implement nice recovery patterns > to almost all possible failure cases via simple shell scripting. Heck, > we can even detect hardware issues with it (illogical startup behavior) > :P
I implemented upstart on an embedded system. Quite like in this situation at the stage we found out all the problems related to Upstart it was to late to switch to something else. Upstart does not have "multi-state" support, nor does it have runlevels. Dependency handling does not work as one would expect as Upstart is inherently not even a state machine but just an event handler. Restart behavior is not well defined Implementing a robust/safe embedded system using upstart is quite a challenge -No support for user id's -No support for setting capabilities -Scripts are run with the "-e" flag so first error results in a failure -Thing tend to go wrong when scripts take some time to start(> 30 seconds) because this is where dbus connection timeouts occurs -As said previously no multi state support so implementing something like suspend/resume is quite hard -No support for sending signals to processes. All I want to say it that *not* choosing for upstart is probably a good choice. _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
