On Nov 29, 2007 5:36 AM, Ismael Luceno <[EMAIL PROTECTED]> wrote: > El Mon, 26 Nov 2007 20:10:17 -0700 > "Shawn Rutledge" <[EMAIL PROTECTED]> escribió: > > On Nov 26, 2007 4:43 PM, Scott James Remnant <[EMAIL PROTECTED]> > > wrote: > > > Debugging interfaces ... why spend time developing debugging > > > interfaces for when init crashes? Why not spend that time making > > > damned sure that init can *NEVER* crash? > > Because that means limiting functionality. > > > > Can save snapshots of the system status ... And why is this > > > useful? If you want to snapshot your system, hibernate it. > > They are good to tell what happened to the system between two events, > "rewinding", and even to make easier to reproduce some bugs.
If you don't have complicated linking of external features into the process, but have seperate process address spaces, you are far less likely to have to do this. Similarly fork-ing an external process, rather than running code in same process (possibly long running external plugins) also avoids complications like multi-threading to avoid blocking when it fails to respond in timely way to events. > > > Services garbage collector ... You don't bother to explain what you > > > mean here, so it's impossible to discuss. > > > It's better to keep some things in memory for some time, so if they are > needed again, you have them already, otherwise you have to recreate > them, and that costs time... So Upstart can use messages to the daemons, via communication protocol. When the process has finished a task on one instance, rather than shutting down, it can sleep on a control event, which could task it to another instance. If the daemon has been unused for a long time, then Upstart can send "TERMINATE" message and restart it on demand later if it's used again. There's going to be an overhead off CPU cycles and memory bloat, adding fancy features, that a "minimalist" implementation does not pay. An event driven init daemon, mostly starts other processes, which are relatively long running, where rapid event rate is expected the client daemons probably would arrange to receive them directly, or support operation via a pool of worker processes. > > If you look at the list of plugins for init-ng, it's longer than I > > would have guessed. They made everything into a plugin... > > Yeah, almost every functionality in initng is implemented by a plug-in; > that makes the development of new/experimental features a lot easier, > just because the new features can coexist with older ones. But this is feeping creaturism, features to ease implementation of other features, few of which seem to be justified by end-user requirements. Sys Admins are concerned with security and stability. When I look at a page like http://www.initng.org/wiki/Documents_Pluginsl frankly it scare the willies ouf of me. For example : libchdir.so - Change Directories "Change current workdir before current launch code is executed" What is wrong with having a shell script wrapper, around a daemon to do that on few occasions it's required? A configuration script option that causes the chdir(2) in the child on forking as a general facility, should reuse script parsing code, and add a few lines only, plus a chdir(2) call in the child after forking before exec. In the Init NG example for libchdir.so http://www.initng.org/browser/initng-ifiles/trunk/initfiles/daemon/vdr.ii it looks like you end up with quite a tricky script anyway. So it doesn't look like there was a real gain. As for "libcpout.so initng's colorful output" and in light of our convesation "libdbus_event.so" I think I stop digging now. -- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
