=== juergbi [n=juerg@80-219-19-101.dclient.hispeed.ch] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === Keybuk [n=scott@quest.netsplit.com] has joined #upstart === cortana [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart === sadleder [n=sadleder@p50811AF2.dip0.t-ipconnect.de] has joined #upstart === sadleder [n=sadleder@p50811AF2.dip0.t-ipconnect.de] has left #upstart [] === mbiebl [n=michael@e180069225.adsl.alicedsl.de] has joined #upstart === tale [n=tale@207.235.54.1] has joined #upstart === sadleder [n=sadleder@p50811AF2.dip0.t-ipconnect.de] has joined #upstart === sadleder [n=sadleder@p50811AF2.dip0.t-ipconnect.de] has left #upstart [] === Ack` [n=Ack@213-140-11-128.fastres.net] has joined #upstart [05:56] heh [05:56] so I explained the c-e-c problem to a friend, and it broke him [05:56] :) [05:57] though he was a sufficient teddy bear for me to figure out two interesting things [05:57] 1) [05:57] states are more interesting than just discreet [05:57] e.g. if you define a state for tty-added...tty-removed for a common NAME, then there are several questions you can answer [05:57] a) does tty1 exist? [05:57] b) does any tty exist? [05:57] c) what is the list of ttys that exist? [05:58] it turns out that all of these are interesting [05:58] getty is run for each tty that exists [05:58] but something requiring a network is running if any non-lo network interface is up [06:00] Perhaps upstart should grow a scheme interpreter after all. ;-) [06:01] and the fhs filesystem question can be answers with list-of-mounted-paths is a superset of list-of-required-paths [06:02] make states scheme procedures, with a nice API for common things. :-) === juergbi [n=juerg@80-219-19-101.dclient.hispeed.ch] has joined #upstart [06:02] this really does make states first class again [06:03] so a job would end up having event predicates and state predicates [06:03] 2) [06:03] states don't need to behave like jobs [06:03] "pre-start"/"post-stop" scripts for states are all very well and pretty [06:03] but in reality, they're not needed [06:03] since you can just tie a job to the state, and define the scripts there [06:04] True... [06:04] But having them in the same file is nice. [06:05] OTOH, you could make them separate, implicitly creating an anonymous job for each state, to which the scripts are added. [06:07] I think it makes it more difficult if they're conceptually the same thing [06:13] Perhaps add an expr stanza for scheme expressions, which could be used by any job. State would be just a job with no process; there would be no distinction from the codes point of view. [06:20] the interesting thing about states is the operations on them [06:20] state-is-true state args... [06:20] any-state-is-true state [06:21] stats-that-are-true state is-subset-of other list [06:21] etc, === jonib1 [n=jonas@ua-83-227-144-18.cust.bredbandsbolaget.se] has joined #upstart === kylem [n=kyle@amnesiac.heapspace.net] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === Keybuk [n=scott@wing-commander.netsplit.com] has joined #upstart [10:30] ho-hum [10:31] ? [10:31] brain hurts [10:32] stop poking at it [10:32] heh [10:33] trying to define an elegant language (and internal combustion) for when jobs should be running [10:37] How about this? /etc/event.d/tty on tty-added $TTY ... tty-removed $TTY; instance would define a job, which also functions as a state. Other jobs/states could query whether tty is running, but they could also query whether an instance (with a certain $TTY) is running. [10:38] In the tty-added $TTY ... tty-removed $TTY expression, the first $TTY (before ...) would be an assignment and the second $TTY (after ...) would be a comparison. [10:38] a job with [10:38] instance [10:38] start on tty-added [10:39] stop on tty-removed $TTY [10:39] would be equivalent [10:39] True. :-) [10:40] so you'd end up with two basic stanzas [10:40] start on/stop on, which define an event or combination of events that start or stop the job [10:40] start on tty-added or serial-port-added [10:40] etc. [10:40] Anyway, that would answer to a) does tty1 exist? b) does any tty exist? c) what is the list of ttys that exist?, wouldnt it? [10:40] you'd also need a second "when" stanza, that defined the other states that must be true [10:41] (or maybe while) [10:41] e.g. [10:41] instance [10:41] start on tty-added tty[1-6] [10:42] stop on tty-removed $TTY [10:42] while user-can-login [10:42] where there's a seperate /etc/?/user-can-login [10:43] /etc/job /etc/state? /etc/job.d /etc/state.d? [10:44] the reason this doesn't feel right to me is that you can't have different pairs of start/stop [10:44] like the tty or serial-port combo [10:44] you can't match the stops to the starts [10:54] :-/ [10:56] on tty-added tty[1-6] until tty-removed \1 or serial-port-added * until serial-port-removed \1 [10:56] Or $1 [10:59] the problem there is how do you stop them doing: [10:59] foo until bar until baz [11:02] Change [11:02] | cmplx_expr 'until' cmplx_expr [11:02] to [11:02] | event 'until' event [11:05] but then you can't do (event or event) until event [11:05] which might be useful [11:05] and how do you define: [11:05] any (tty-added until tty-removed $TTY) [11:09] expr_no_until : event | expr_no_until 'and' expr_no_until | expr_no_until 'or' expr_no_until | '(' expr_no_until ')' ; expr : expr_no_until | expr_no_until 'until' expr_no_until ; [11:10] Correction: [11:10] expr_no_until : event | expr_no_until 'and' expr_no_until | expr_no_until 'or' expr_no_until | '(' expr_no_until ')' ; expr : event | expr 'and' expr | expr 'or' expr | '(' expr ')' | expr_no_until 'until' expr_no_until ; [11:12] For any (tty-added * until tty-removed $1), create job (state) instance; on tty-added * until tty-removed $1 and check whether it is running. [11:14] whether any instance is running? [11:14] Yes. [11:15] that gets quite expensive if used a lot, no? [11:17] Disconnect state names from the filenames, and make it possible to assign a number of state expressions to variables in a single file? [11:19] state tty-exists = any (tty-added tty[1-6] until tty-removed $1) [11:20] state foo = tty-exists and writable-filesystem === cortana [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart