<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Garrett Cooper wrote:
<blockquote
cite="mid:364299f40810291051t5efce034r8bbe4ca42ec95103@mail.gmail.com"
type="cite">
<pre wrap="">On Wed, Oct 29, 2008 at 10:28 AM, Scott James Remnant
<a class="moz-txt-link-rfc2396E" href="mailto:scott@netsplit.com"><scott@netsplit.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Wed, 2008-10-29 at 10:03 -0700, Garrett Cooper wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">reload is to reload all job definitions from disk, it's really quite
expensive compared to start - which just changes a job state.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">Reload is intentionally expensive. It is a complete flush and reload of
the internal state.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
<pre wrap="">Upstart should reload them itself by watching the directory with
inotify.
</pre>
</blockquote>
<pre wrap="">Hmm... ok. So this isn't implemented, but it's slated?
</pre>
</blockquote>
<pre wrap="">This is absolutely implemented, and has been since the earliest versions
of Upstart.
Scott
</pre>
</blockquote>
<pre wrap=""><!---->
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
</pre>
</blockquote>