=== HTSJacket [n=kevin@c-24-98-52-235.hsd1.ga.comcast.net] has joined #upstart [06:13] 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? === jonib1 [n=jonas@213.212.2.165] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === asdaf [n=Ack@213-140-11-128.fastres.net] has joined #upstart === reppel [n=reppel@213-140-11-128.fastres.net] has joined #upstart === Keybuk [n=scott@quest.netsplit.com] has joined #upstart === reppel [n=reppel@213-140-11-128.fastres.net] has joined #upstart [10:20] morning all [10:20] why upstart does not pass kernel cmdline argumments as env variables to jobs? [10:20] hi Keybuk [10:21] reppel: because it doesn't yet (missing feature) [10:21] Keybuk: ah ok [10:21] jobs should be able to select which variables they want to receive with "env VAR" in their definition [10:22] Keybuk: nice === Starting logfile irclogs/upstart.log === ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog] has joined #upstart === Topic for #upstart: Upstart 0.3.8 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/UpstartOnGentoo === Topic (#upstart): set by Md at Sun May 6 19:59:46 2007 === juergbi [n=juerg@80-219-16-162.dclient.hispeed.ch] has joined #upstart === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart === tale [n=tale@207.235.54.1] has joined #upstart [03:36] hmm [03:36] who needs config file code anyway? === shawarma [n=sh@atlas.linux2go.dk] has joined #upstart [05:11] 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] yes [05:12] there's no way (yet) to make it reload that list [05:12] I see. Hm. [05:13] That kind of sucks. :) [05:13] why? [05:13] (do you need to make it reload) [05:13] I want to have upstart manage a newly added daemon. [05:13] So yes, I need to make it reload. [05:13] Unless I'm missing something obvious? [05:13] It's been known to happen.. :( [05:15] why not just write the file? :) [05:15] bet you if you do "initctl list", the new daemon's there [05:15] inotify is a wonderful thing [05:15] [05:16] Keybuk: It seems not? [05:16] which version of upstart/ [05:16] oh.. [05:17] Not making syntax errors in the job file helps a lot. [05:17] :) [05:17] how does it ensure that it only reads the file once it's been written? [05:17] or can inotify tell you that the newly-created file has been closed === Md [i=md@freenode/staff/md] has joined #upstart === mbiebl [n=michael@e180070168.adsl.alicedsl.de] has joined #upstart [05:21] cort: IN_CLOSE_WRITE [05:21] cool [05:21] (closed and written to) [05:22] When does upstart consider a job to be started? [05:22] I.e. without --no-wait, when will "start jobname" terminate? [05:23] depends whether it's a task or a service [05:23] Since it's a deamon I want supervised, I expect I should pass it arguments to run in the foreground? [05:23] if it's a task, start will not terminate until the job terminates [05:23] if it's a service, start will terminate once the job is running [05:23] right [05:23] you should make sure it runs in the foreground [05:23] and make sure "respawn" is in the job definition [05:23] it helps not to leave duplicate values around in the profile from testing [05:24] heh [05:24] I changed the job code today to not bitch about duplicate stanzas [05:25] heh [05:25] Keybuk: Oh, so "respawn" tells it that it's a service? Got it. [05:25] shawarma: respawn tells it that it's a service that should be respawned [05:25] shawarma: "service" tells it that it's a service that should not be === AlexExtreme will have fun merging the changes in main to the profiles branch [05:25] Keybuk: Oh, ok. [05:25] AlexExtreme: did you look at them yet? [05:26] not in detail yet [05:26] it should make things a lot easier for you [05:26] you just need a parse_profile.c with a parse_profile() function [05:26] sweet [05:26] takes the usual file, len, pos, lineno parameters, and probably has stanza_*() functions and a table to parse that block of text [05:27] pretty much everything else will be handled for you [05:27] (watching the directory, tracking reloads & deletes, etc.) [05:27] nice === AlexExtreme reads through his commit mails [05:29] you get commit mails? [05:29] yeah [05:29] if you subscribe to a branch you can configure it to send you mails on new commits ;) [05:29] neat [05:29] does it attach diffs? [05:30] yep, as long as the diff is under a certain size [05:30] shiny [05:30] I never knew about that [05:30] The size of the diff (10342 lines) is larger than your specified limit of 1000 lines [05:30] yeah, i only found that feature the other day ;) === AlexExtreme likes launchpad [05:31] what diff was that?! [05:32] rev 693 [05:34] wow [05:34] no wonder my fingers hurt yesterday [05:35] :P [05:35] oh, 696 is bigger ;) [05:35] 2968 lines [05:37] 2968 < 10342 ? [05:38] whoops [05:39] misread it with an 0 on the end for some reason :p [05:39] s/an/a/ [05:51] so, with the new code, i would ignore duplicate values and overwrite the old value with the new one instead? [05:52] right [05:52] k [05:53] Keybuk: I spotted a small glitch. Patch is here: http://pastebin.ca/536963 [05:54] mbiebl: yeah, that'll be needed, thx [06:04] committed [06:06] brb, testing the NihHash-ified profile code [06:14] Keybuk: thx [06:15] /* FIXME: Read configuration */ << if we don't read the configuration, does this mean the current bzr doesn't work? :) [06:15] right === AlexExtreme will hold back on updating the profiles branch to the latest main then :p [06:17] 08:23 is it bad to push incomplete code to main? :p [06:17] just checking in case you've made it working today [06:17] no, not yet [06:17] it's a complex problem that I want to solve [06:18] and I find it difficult to work in the afternoon, for some reason [06:18] heh [06:18] np [06:19] btw, i'm assuming we shouldn't disable jobs from automatically starting on the stalled event? === cort [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart [06:41] AlexExtreme: why not? [06:43] 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] quest upstart% bzr diff -rtag:0.3.8.. | diffstat | tail -1 [06:48] 34 files changed, 7423 insertions(+), 6014 deletions(-) [06:48] whee [06:51] http://codebrowse.launchpad.net/~keybuk/upstart/main/changes << umm :P [06:51] 500 Internal error [06:51] The server encountered an unexpected condition which prevented it from fulfilling the request. [06:57] poked lp [06:59] k [07:41] AlexExtreme: heh, broken by having tags, apparently [07:41] lol === Keybuk is still trying to figure out the registry stuff [08:46] it's a little complex right now [08:47] the theory is: [08:47] - a hash table for each type (Job, State, Profile, etc.) [08:48] - 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] when we parse a config file, we add all entries to the available list in their relevant namespace [08:50] then if the current holder of the name is replaceable immediately, we pick the new best current name === Keybuk [n=scott@wing-commander.netsplit.com] has joined #upstart