On Wed, Oct 29, 2008 at 10:28 AM, Scott James Remnant <[EMAIL PROTECTED]> wrote: > On Wed, 2008-10-29 at 10:03 -0700, Garrett Cooper wrote: > >> > reload is to reload all job definitions from disk, it's really quite >> > expensive compared to start - which just changes a job state. >> >> What I meant is overall initctl reload uses up a large amount of >> resources; I was just wondering if there was a more lightweight >> alternative planned because we may potentially be reloading the >> configuration frequently, in such a case it wouldn't make sense to >> reload all of the files necessarily -- just the ones that have >> changed. >> > Reload is intentionally expensive. It is a complete flush and reload of > the internal state. > >> >> We >> >> currently use initctl reload for getting new jobs loaded into upstart >> >> init; however, I was wondering whether or not: >> >> 1. The method of getting new job definitions was the best choice. >> >> >> > Upstart should reload them itself by watching the directory with >> > inotify. >> >> Hmm... ok. So this isn't implemented, but it's slated? >> > This is absolutely implemented, and has been since the earliest versions > of Upstart. > > Scott
So maybe implementing a subcommand like `initctl update' or `initctl refresh' would be a good thing to do, such that it wouldn't touch the state of unchanged jobs, but just update and append any missing data and delete stale job info from the upstart's core job data. It seems like one could do this properly, and avoid a lot of overhead. On the other hand, maybe the actual issue is that inotify isn't be used properly within upstart. After reading through the manpage description it appears that there are a number of items for filesystem access that are available via inotify. inotify shouldn't be an expensive operation and should be an indicator as to whether or not the configuration data should be reloaded (maybe) for refreshing the core job data and potentially state. The last item's a conjecture and I need to hunt through the code to see where it's implemented to see whether or not that's actually the case. Thanks! -Garrett -- upstart-devel mailing list upstart-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
