=== _ion [i=johan@kiviniemi.name] has joined #upstart === khermans__ [i=administ@nat/cisco/x-d2e541840bf269f5] has joined #upstart === theCore [n=alex@ubuntu/member/theCore] has joined #upstart === j_ack [n=rudi@p508DB9B4.dip0.t-ipconnect.de] has joined #upstart === redear [n=redear@bas12-toronto63-1088806045.dsl.bell.ca] has joined #upstart === redear [n=redear@bas12-toronto63-1088806045.dsl.bell.ca] has left #upstart [] === j_ack [n=rudi@p508DB9B4.dip0.t-ipconnect.de] has joined #upstart === khermans__ [i=administ@nat/cisco/x-5b11189a6dd99d5c] has joined #upstart === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart === pkt [n=pantelis@87.203.113.181] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === Keybuk [n=scott@quest.netsplit.com] has joined #upstart === pkt [n=pantelis@85.75.157.215] has joined #upstart === mdales [n=mdales@cpc3-cmbg6-0-0-cust25.cmbg.cable.ntl.com] has joined #upstart [10:47] morning [10:48] morning Keybuk [10:48] thanks for your help yesterday, my system seems to be doing what I want now :) [10:49] cool :) no problem [10:49] thought I'd loiter for a bit still as I learned a bit from just watching the general chat here yesterday === pkt [n=pantelis@athedsl-137442.otenet.gr] has joined #upstart [11:53] hmm [11:53] action reload script [11:53] ... [11:53] end script [11:53] action reload on some-event [11:53] syntax could use some work there :-/ === mdales_ [n=mdales@cpc3-cmbg6-0-0-cust25.cmbg.cable.ntl.com] has joined #upstart [01:24] action reload [01:24] on some-event [01:25] script [01:25] .. [01:25] end script [01:25] end action [01:25] that might work [01:25] <_ion> Looks quite intuitive. [01:30] need to sort out the job status messages first though === Keybuk made things a wee bit more complicated :p [02:17] for a given job, "foo", there may be: [02:18] - old versions running from before the config file was modified [02:18] - a master instance that never runs [02:18] - multiple running instances [02:18] - or a single instance of the job [02:18] and for each instance, there may be: [02:18] - a "main stream" process (pre-start, main, post-start) [02:18] - a "side stream" process (post-start, pre-stop) [02:18] - any number of user actions [02:21] start foo => obviously only cares about the master/single instance of current versions [02:22] stop foo => only needs to care about single or multiple instances, but of both current and old versions [02:22] status foo => probably cares about them all? [02:25] this comes back to how instances are implemented [02:25] right now they're just extra entries in the hash table [02:25] perhaps separating all the non-config state into a JobInstance structure, and having a list of those in the job, is one way to do it === mdales [n=mdales@cpc3-cmbg6-0-0-cust25.cmbg.cable.ntl.com] has joined #upstart === pkt [n=pantelis@athedsl-157104.otenet.gr] has joined #upstart === wasabi [n=wasabi@ubuntu/member/wasabi] has joined #upstart === j_ack [n=rudi@p508DBA65.dip0.t-ipconnect.de] has joined #upstart === pkt [n=pantelis@athedsl-81335.otenet.gr] has joined #upstart === pkt_ [n=pantelis@87.203.71.5] has joined #upstart === AStorm [n=astralst@chello084010114027.chello.pl] has joined #upstart === pkt [n=pantelis@87.203.71.5] has joined #upstart === pkt [n=pantelis@87.203.71.5] has joined #upstart [05:07] *giggles* === Keybuk finds silly bugs [05:07] a deleted job can't stop [05:07] because the job_change_goal() function won't let you run it for a deleted job [05:07] heh === Keybuk wonders if anyone will ever reach 4 billion jobs or events on a running system === AlexExtreme highly doubts that [05:59] AlexExtreme: we'll quote you on that in 5 years when 32 bit pids are a cause of global concern [05:59] :D [05:59] They are a cause for concern right now in my world. [05:59] Heh. [05:59] it doesn't matter, I've deliberately put in code to cope with it just in case [06:00] that branch is sub-optimal though [06:00] since once the counter wraps, it has to scan the entire jobs hash each time you want to add a new one to ensure uniqueness [06:00] (there's probably a clever way to avoid that) === mbiebl [n=michael@e180099068.adsl.alicedsl.de] has joined #upstart [06:03] oh, pids. n/m. [06:03] for whatever reason my mind thought uid [06:09] not pids [06:09] the Job and EventEmission structures have a unique id field [06:09] so you know *which* "foo" job, and which "block-device-added" event it is [06:09] uh huh [06:09] they're uint32_t, which wraps after 4 billion job file changes, or 4 billion initctl emits [06:09] (or 4 billion job state changes) [06:10] obviously once wrapped, job->id = job_id++ is no longer guaranteed to be unique [06:15] so you need to scan before allocating. [06:15] right [06:15] but only once we've wrapped once [06:15] store a "lowest known job id value". update it when you lease/release a number. when leasing one, use the "last known one ++" and check if it's < the lowest known. if not, do teh forward scan. [06:15] the "update when release" is the tricky bit :p [06:16] well you only have to update on release when release == current lowest known [06:17] none of which really matters anyways. [06:17] the jobs hash is going to be small enough for it to not matter. [06:21] indeed [06:21] and job creation isn't a time-critical activity [06:22] in fact, upstart has no time critical activities :p [06:22] only at boot. and that won't have looped anyways === j_ack [n=rudi@p508DBA65.dip0.t-ipconnect.de] has joined #upstart === khermans__ [i=administ@nat/cisco/x-7d93a3df3729d245] has joined #upstart === juergbi [n=juerg@80-219-17-102.dclient.hispeed.ch] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === pkt [n=pantelis@athedsl-281822.otenet.gr] has joined #upstart === pkt [n=pantelis@athedsl-136147.otenet.gr] has joined #upstart === j_ack [n=rudi@p508DBA65.dip0.t-ipconnect.de] has joined #upstart === mdales [n=mdales@dsl-217-155-205-58.zen.co.uk] has joined #upstart === mbiebl [n=michael@e180099068.adsl.alicedsl.de] has joined #upstart === theCore [n=alex@ubuntu/member/theCore] has joined #upstart