On Wed, Oct 29, 2008 at 12:30 PM, Jeff Oliver <[EMAIL PROTECTED]> wrote: > > Garrett Cooper wrote: > > 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 > > > > From what I understand, inotify does the job as it should, no longer > requiring the use of initctl reload at all in normal use. The "typical" use > cases of initctl reload allows it to be an expensive operation. > > Are you implying that your new jobs are not showing up in the list as you > create them? > > Jeff Oliver
NOW I understand why the original test writer did what he did. Ok... So basically what is happening is we are using TFTPboot + NFS to execute testcases, and because inotify isn't capable of detecting NFS server filechanges, the new file would go onto the targets NFS area unnoticed. I discovered a quick, inexpensive workaround for this issue though, which is to touch the jobfiles after a copy on the target, which forces upstart to reread the file and as such initctl reload isn't required (YAY!) :)... -Garrett -- upstart-devel mailing list upstart-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
