[06:13] <HTSJacket> I'm having trouble understanding this sentence in the getting started page: This should be one of output (input and output from /dev/console), owner (as output and Control-C also sent the process) or none (the default; input and output to /dev/null).  Can anyone explain what "as output and Control-C also sent the process" means here?
[10:20] <Keybuk> morning all
[10:20] <reppel> why upstart does not pass kernel cmdline argumments as env variables to jobs?
[10:20] <reppel> hi Keybuk 
[10:21] <Keybuk> reppel: because it doesn't yet (missing feature)
[10:21] <reppel> Keybuk: ah ok
[10:21] <Keybuk> jobs should be able to select which variables they want to receive with "env VAR" in their definition
[10:22] <reppel> Keybuk: nice
[03:36] <Keybuk> hmm
[03:36] <Keybuk> who needs config file code anyway?
[05:11] <shawarma> Does upstart have some sort of in-memory idea about which jobs exist? If so, how do I make it rethink that list?
[05:12] <Keybuk> yes
[05:12] <Keybuk> there's no way (yet) to make it reload that list
[05:12] <shawarma> I see. Hm.
[05:13] <shawarma> That kind of sucks. :)
[05:13] <Keybuk> why?
[05:13] <Keybuk> (do you need to make it reload)
[05:13] <shawarma> I want to have upstart manage a newly added daemon.
[05:13] <shawarma> So yes, I need to make it reload.
[05:13] <shawarma> Unless I'm missing something obvious?
[05:13] <shawarma> It's been known to happen.. :(
[05:15] <Keybuk> why not just write the file? :)
[05:15] <Keybuk> bet you if you do "initctl list", the new daemon's there
[05:15] <Keybuk> inotify is a wonderful thing

[05:16] <shawarma> Keybuk: It seems not?
[05:16] <Keybuk> which version of upstart/
[05:16] <shawarma> oh..
[05:17] <shawarma> Not making syntax errors in the job file helps a lot.
[05:17] <shawarma> :)
[05:17] <cort> how does it ensure that it only reads the file once it's been written?
[05:17] <cort> or can inotify tell you that the newly-created file has been closed
[05:21] <Keybuk> cort: IN_CLOSE_WRITE
[05:21] <cort> cool
[05:21] <Keybuk> (closed and written to)
[05:22] <shawarma> When does upstart consider a job to be started?
[05:22] <shawarma> I.e. without --no-wait, when will "start jobname" terminate?
[05:23] <Keybuk> depends whether it's a task or a service
[05:23] <shawarma> Since it's a deamon I want supervised, I expect I should pass it arguments to run in the foreground?
[05:23] <Keybuk> if it's a task, start will not terminate until the job terminates
[05:23] <Keybuk> if it's a service, start will terminate once the job is running
[05:23] <Keybuk> right
[05:23] <Keybuk> you should make sure it runs in the foreground
[05:23] <Keybuk> and make sure "respawn" is in the job definition
[05:23] <AlexExtreme> it helps not to leave duplicate values around in the profile from testing <g>
[05:24] <Keybuk> heh
[05:24] <Keybuk> I changed the job code today to not bitch about duplicate stanzas
[05:25] <AlexExtreme> heh
[05:25] <shawarma> Keybuk: Oh, so "respawn" tells it that it's a service? Got it.
[05:25] <Keybuk> shawarma: respawn tells it that it's a service that should be respawned
[05:25] <Keybuk> shawarma: "service" tells it that it's a service that should not be
[05:25] <shawarma> Keybuk: Oh, ok.
[05:25] <Keybuk> AlexExtreme: <g> did you look at them yet?
[05:26] <AlexExtreme> not in detail yet
[05:26] <Keybuk> it should make things a lot easier for you
[05:26] <Keybuk> you just need a parse_profile.c with a parse_profile() function
[05:26] <AlexExtreme> sweet
[05:26] <Keybuk> takes the usual file, len, pos, lineno parameters, and probably has stanza_*() functions and a table to parse that block of text
[05:27] <Keybuk> pretty much everything else will be handled for you
[05:27] <Keybuk> (watching the directory, tracking reloads & deletes, etc.)
[05:27] <AlexExtreme> nice
[05:29] <Keybuk> you get commit mails?
[05:29] <AlexExtreme> yeah
[05:29] <AlexExtreme> if you subscribe to a branch you can configure it to send you mails on new commits ;)
[05:29] <Keybuk> neat
[05:29] <Keybuk> does it attach diffs?
[05:30] <AlexExtreme> yep, as long as the diff is under a certain size
[05:30] <Keybuk> shiny
[05:30] <Keybuk> I never knew about that
[05:30] <AlexExtreme> The size of the diff (10342 lines) is larger than your specified limit of 1000 lines
[05:30] <AlexExtreme> yeah, i only found that feature the other day ;)
[05:31] <Keybuk> what diff was that?!
[05:32] <AlexExtreme> rev 693
[05:34] <Keybuk> wow
[05:34] <Keybuk> no wonder my fingers hurt yesterday
[05:35] <AlexExtreme> :P
[05:35] <AlexExtreme> oh, 696 is bigger ;)
[05:35] <AlexExtreme> 2968 lines
[05:37] <Keybuk> 2968 < 10342 ?
[05:38] <AlexExtreme> whoops
[05:39] <AlexExtreme> misread it with an 0 on the end for some reason :p
[05:39] <AlexExtreme> s/an/a/
[05:51] <AlexExtreme> so, with the new code, i would ignore duplicate values and overwrite the old value with the new one instead?
[05:52] <Keybuk> right
[05:52] <AlexExtreme> k
[05:53] <mbiebl> Keybuk: I spotted a small glitch. Patch is here: http://pastebin.ca/536963
[05:54] <Keybuk> mbiebl: yeah, that'll be needed, thx
[06:04] <Keybuk> committed
[06:06] <AlexExtreme> brb, testing the NihHash-ified profile code
[06:14] <mbiebl> Keybuk: thx
[06:15] <AlexExtreme>         /* FIXME: Read configuration */ << if we don't read the configuration, does this mean the current bzr doesn't work? :)
[06:15] <Keybuk> right
[06:17] <Keybuk> 08:23 <Keybuk> is it bad to push incomplete code to main? :p
[06:17] <AlexExtreme> just checking in case you've made it working today
[06:17] <Keybuk> no, not yet
[06:17] <Keybuk> it's a complex problem that I want to solve
[06:18] <Keybuk> and I find it difficult to work in the afternoon, for some reason
[06:18] <AlexExtreme> heh
[06:18] <AlexExtreme> np
[06:19] <AlexExtreme> btw, i'm assuming we shouldn't disable jobs from automatically starting on the stalled event?
[06:41] <Keybuk> AlexExtreme: why not?
[06:43] <AlexExtreme> because say a user does "disable *" and doesn't enable any jobs specifically, the system will just hang at boot with no useful message. surely it should give them an opportunity to login and fix their blunder?
[06:48] <Keybuk> quest upstart% bzr diff -rtag:0.3.8.. | diffstat | tail -1
[06:48] <Keybuk>  34 files changed, 7423 insertions(+), 6014 deletions(-)
[06:48] <Keybuk> whee
[06:51] <AlexExtreme> http://codebrowse.launchpad.net/~keybuk/upstart/main/changes << umm :P
[06:51] <AlexExtreme> 500 Internal error
[06:51] <AlexExtreme> The server encountered an unexpected condition which prevented it from fulfilling the request.
[06:57] <Keybuk> poked lp
[06:59] <AlexExtreme> k
[07:41] <Keybuk> AlexExtreme: heh, broken by having tags, apparently
[07:41] <AlexExtreme> lol
[08:46] <Keybuk> it's a little complex right now
[08:47] <Keybuk> the theory is:
[08:47] <Keybuk>  - a hash table for each type (Job, State, Profile, etc.)
[08:48] <Keybuk>  - each entry is a Name structure that has the name, a pointer to the current holder of that name, and a list of available entries with that name
[08:49] <Keybuk> when we parse a config file, we add all entries to the available list in their relevant namespace
[08:50] <Keybuk> then if the current holder of the name is replaceable immediately, we pick the new best current name