=== _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 | ||
Keybuk | morning | 10:47 |
---|---|---|
mdales | morning Keybuk | 10:48 |
mdales | thanks for your help yesterday, my system seems to be doing what I want now :) | 10:48 |
Keybuk | cool :) no problem | 10:49 |
mdales | thought I'd loiter for a bit still as I learned a bit from just watching the general chat here yesterday | 10:49 |
=== pkt [n=pantelis@athedsl-137442.otenet.gr] has joined #upstart | ||
Keybuk | hmm | 11:53 |
Keybuk | action reload script | 11:53 |
Keybuk | ... | 11:53 |
Keybuk | end script | 11:53 |
Keybuk | action reload on some-event | 11:53 |
Keybuk | syntax could use some work there :-/ | 11:53 |
=== mdales_ [n=mdales@cpc3-cmbg6-0-0-cust25.cmbg.cable.ntl.com] has joined #upstart | ||
Keybuk | action reload | 01:24 |
Keybuk | on some-event | 01:24 |
Keybuk | script | 01:25 |
Keybuk | .. | 01:25 |
Keybuk | end script | 01:25 |
Keybuk | end action | 01:25 |
Keybuk | that might work | 01:25 |
_ion | Looks quite intuitive. | 01:25 |
Keybuk | need to sort out the job status messages first though | 01:30 |
=== Keybuk made things a wee bit more complicated :p | ||
Keybuk | for a given job, "foo", there may be: | 02:17 |
Keybuk | - old versions running from before the config file was modified | 02:18 |
Keybuk | - a master instance that never runs | 02:18 |
Keybuk | - multiple running instances | 02:18 |
Keybuk | - or a single instance of the job | 02:18 |
Keybuk | and for each instance, there may be: | 02:18 |
Keybuk | - a "main stream" process (pre-start, main, post-start) | 02:18 |
Keybuk | - a "side stream" process (post-start, pre-stop) | 02:18 |
Keybuk | - any number of user actions | 02:18 |
Keybuk | start foo => obviously only cares about the master/single instance of current versions | 02:21 |
Keybuk | stop foo => only needs to care about single or multiple instances, but of both current and old versions | 02:22 |
Keybuk | status foo => probably cares about them all? | 02:22 |
Keybuk | this comes back to how instances are implemented | 02:25 |
Keybuk | right now they're just extra entries in the hash table | 02:25 |
Keybuk | 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 | 02:25 |
=== 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 | ||
Keybuk | *giggles* | 05:07 |
=== Keybuk finds silly bugs | ||
Keybuk | a deleted job can't stop | 05:07 |
Keybuk | because the job_change_goal() function won't let you run it for a deleted job | 05:07 |
AlexExtreme | heh | 05:07 |
=== Keybuk wonders if anyone will ever reach 4 billion jobs or events on a running system | ||
=== AlexExtreme highly doubts that | ||
mdales | AlexExtreme: we'll quote you on that in 5 years when 32 bit pids are a cause of global concern | 05:59 |
AlexExtreme | :D | 05:59 |
wasabi_ | They are a cause for concern right now in my world. | 05:59 |
wasabi_ | Heh. | 05:59 |
Keybuk | it doesn't matter, I've deliberately put in code to cope with it just in case | 05:59 |
Keybuk | that branch is sub-optimal though | 06:00 |
Keybuk | 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 |
Keybuk | (there's probably a clever way to avoid that) | 06:00 |
=== mbiebl [n=michael@e180099068.adsl.alicedsl.de] has joined #upstart | ||
wasabi_ | oh, pids. n/m. | 06:03 |
wasabi_ | for whatever reason my mind thought uid | 06:03 |
Keybuk | not pids | 06:09 |
Keybuk | the Job and EventEmission structures have a unique id field | 06:09 |
Keybuk | so you know *which* "foo" job, and which "block-device-added" event it is | 06:09 |
wasabi_ | uh huh | 06:09 |
Keybuk | they're uint32_t, which wraps after 4 billion job file changes, or 4 billion initctl emits | 06:09 |
Keybuk | (or 4 billion job state changes) | 06:09 |
Keybuk | obviously once wrapped, job->id = job_id++ is no longer guaranteed to be unique | 06:10 |
wasabi_ | so you need to scan before allocating. | 06:15 |
Keybuk | right | 06:15 |
Keybuk | but only once we've wrapped once | 06:15 |
wasabi_ | 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 |
Keybuk | the "update when release" is the tricky bit :p | 06:15 |
wasabi_ | well you only have to update on release when release == current lowest known | 06:16 |
wasabi_ | none of which really matters anyways. | 06:17 |
wasabi_ | the jobs hash is going to be small enough for it to not matter. | 06:17 |
Keybuk | indeed | 06:21 |
Keybuk | and job creation isn't a time-critical activity | 06:21 |
Keybuk | in fact, upstart has no time critical activities :p | 06:22 |
wasabi_ | only at boot. and that won't have looped anyways | 06:22 |
=== 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 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!