=== Keybuk [n=scott@wing-commander.netsplit.com] has joined #upstart === Keybuk had an interesting idea last night [12:38] oh? [12:39] concerning how Status and Job interact [12:41] so let's say we have a service that uses this: [12:41] while interface-up until interface-down $IFACE [12:41] that defines a simple state period between an interface coming up and going down again [12:42] the state would keep a record of ALL interface-up events [12:42] and ALL of them would have to be cancelled before the interface could go down [12:42] ie. that defines a service running while any network interface is up [12:44] a simple modification: [12:44] while interface-up until interface-down $IFACE [12:44] instance [12:44] this job behaves differently; now each time an interface comes up, a new instance of the job is spawned, and that instance runs until the interface it was spawned for goes down [12:48] since states can be canned (and for other reasons) you'll want to be able to restrict which interfaces this is true for [12:48] so you'd allow something like [12:48] state interface-is-up [12:49] while interface-up until interface-down $IFACE [12:49] end state [12:49] -- [12:49] while interface-is-up ~lo === Md [i=md@freenode/staff/md] has joined #upstart [12:56] the other change to make is to Event [12:56] I'm going to get rid of different positional and name-based variables [12:56] instead it's going to have just name-based ones, but in a particular order [12:56] so an event might be [12:57] stopping JOB=apache RESULT=failed FAILED_PROCESS=main [12:57] and for matching in job definitions, you can omit the names in order until you give the first name [12:57] but the scripts won't receive any arguments, just them as environment variables [12:58] so we won't be able do have events like "interface-up eth0", instead it would be "interface up IFACE=eth0" ? [01:00] you cam omit the name provided eth0 is the first event in the list [01:00] (which it would be) [01:10] in effect, they become like python method calls [01:13] this makes figuring out what to pass to the jobs MUCH easier ;) [01:13] since there's no worry about which gets $1, $2, etc. they all get arguments by name! [01:13] likewise [01:14] interface-up until interface-down $IFACE [01:14] is more obvious than [01:14] interface-up until interface-down $1 [01:14] yes [01:18] Sounds good. [01:24] ion_: does the state/instance stuff make sense? [01:26] In what situations would counting the number of up events and waiting for the number of down events to match is necessary? [01:28] How about adding a new state to a running system it would have no knowledge of recently emitted events it needs to track. [01:29] Oh, i misunderstood the intent. Ignore the In what situations... line. [01:29] not so much counting, but matching pairs [01:29] and keeping track of which interfaces are still up [01:29] Yeah, i realized that. :-) [01:29] it makes a lot of sense to have a service running while at least one network interface is up [01:32] Regarding the interface-is-up alias, id like the syntax to be more like: while interface-is-up IFACE=~lo until interface-down $IFACE, where the first part would be a fnmatch-ish match against the variable and the second part would match against the stored value. [01:32] Something like... [01:33] while interface-is-up IFACE=* until interface-down $IFACE [01:33] would be equivalent to [01:33] while interface-is-up IFACE until interface-down $IFACE [01:33] The difference to [01:33] while interface-is-up IFACE until interface-down IFACE [01:34] would be that any interface-is-up ... interface-down pair would match, since the IFACE value isnt compared to anything. [01:34] interface-down $IFACE would point to the value implicitly stored by interface-is-up IFACE [01:36] I'm not sure I follow [01:37] you mean interface-up (an event) not interface-is-up? [01:37] Ah, sorry. I meant interface-up [01:37] ah, you mean name the variables on the left you intend to use on the right? [01:37] interface-up IFACE until interface-down $IFACE [01:37] not [01:37] Yes. [01:37] That would allow more complex matches, such as: [01:37] interface-up until interface-down $IFACE [01:37] while interface-up ADDR=10.0.0.* IFACE until interface-down $IFACE [01:38] I don't see why the IFACE bit is needed? [01:38] that would work [01:38] while interface-up ADDR=10.0.0.* until interface-down $IFACE [01:38] ? [01:39] True. Just store all the variables by default, so that any of them could be matched against in the until part. [01:39] So IFACE would need to be mentioned in the first part *only* if its matched against something. [01:40] while interface-up IFACE=~lo until interface-down $IFACE [01:40] while interface-up until interface-down $IFACE [01:40] while interface-up ADDR=10.0.0.* until interface-down $IFACE [01:40] for example [01:41] Perhaps IFACE!=lo instead? [01:41] yeah, either works doesn't it [01:41] actually, I prefer != [01:41] ADDR!=10.* [01:43] Anyway, that would remove the need to define a named alias just to be able to give patterns. Of course, aliases might be very useful for other purposes. [01:43] the named alias would be for complex things like "user-can-login" [01:43] Yeah [01:44] if state allows spawning like this, then we could have structures like for loops in there [01:45] for PATH in `getmntent -fD` path-mounted $PATH until path-unmounted $PATH [01:45] :p [01:47] NEat. [01:48] Perhaps make it block-like [01:48] for PATH in $(getmntent -fD) [01:48] while path-mounted $PATH until path-unmounted $PATH [01:48] end for [01:49] that could work too === phoenix24 [n=phoenix2@59.176.23.106] has joined #upstart [01:50] Another idea that accomplishes the same thing a bit differently: assign the output of getmntent -fD to an array variable, and do a single while expression that matches PATH to the array. [01:54] Also, an interface-up event might have multiple ADDR variables. It should be possible to match against any of them, or all of them. [01:54] how would you define/match that? [01:58] interface-up any(ADDR or(ADDR=127.* ADDR=::1)), where any would loop through ADDR variables and return true if any of the expressions return true. That syntax is ugly, though, but it can be improved. :-) [02:00] (any? ADDR (or ((match? ADDR "127.*") (match? ADDR "::1")))) ;-) [02:01] (all? ADDR (match? ADDR "*:*")) IPv6-only interface [02:05] Just like for foo in ADDR, do something with foo, but simplified to for ADDR, do something with ADDR, where inside the loop, ADDR is the value currently being iterated. [02:13] (blah ((mountpoints "getmntent -fD")) (any? mountpoints (eq? mountpoints PATH))) [02:15] Im definitely not saying thats what the syntax should be, just formulating ideas about how things could be matched. [02:22] I've found lisp/scheme-like syntax easier to work things out in too [02:22] simply because it's already in the same shape as the necessary syntax tree to evaluate it [02:23] rather than the latter [02:24] uh, rather than the humanish way of putting it [02:24] what does the mountpoints thing do? [02:27] Um, just assigns the output of the command to an array variable. Then the arrays compared to the PATH variable. [02:27] mountpoints.any? {|dir| env[:PATH] == dir } # Ruby syntax :-) === Amaranth_ [n=travis@ubuntu/member/Amaranth] has joined #upstart === mbiebl [n=michael@p549cdf03.dip.t-dialin.net] has joined #upstart === penguin42 [n=dg@tu006.demon.co.uk] has joined #upstart === penguin42 yawns [03:56] I fancy adding a --host to the reboot/shutdown/halt utilities to check that the host you specify is the one you think you are trying to shut down [03:57] I was also considering requiring it if it's run from a tty - anyone have strong views? [03:58] heh [03:58] interesting patch ;) [03:58] one too many halts of the wrong machine :-) [04:00] I can't think of anything shorter than --host that would work on all of reboot/shutdown/halt [04:00] you'd need to give the hostname [04:00] shutdown -h quest [04:00] yeh exactly [04:01] except shutdown already has a -h for example === penguin42 will put something together - where is a good place to send the patch? [04:07] the bug tracker at launchpad probably [04:07] oh ok, I hadn't realised people used launchpad for patch stuff as well [04:09] penguin42: upstart-devel@lists.ubuntu.com [04:09] or launchpad, yeah [04:10] if you prefer, make a bzr branch of upstart and upload your branch to LP [04:11] ok, I'll probably launchpad it since I've already got a launchpad account; probably just a patch for the moment unless I fancy figuring out the branch stuff [04:12] :) === AlexExtreme loves bzr :P [04:20] yeah, it's not terrible [04:20] is bzr yet-another-source-code-control thing? [04:22] yep [04:27] Why does 'reboot' scan only ide discs to power them down? [04:29] penguin42: it doesn't even need to do that [04:29] originally it was because the code was copied from sysvinit, and only ide disks existed then [04:30] now the kernel automatically does it [04:30] ah ok [04:31] reboot does seem to have a small random selection of clean up things in it [04:31] yeah [04:31] our goal is to eliminate both [05:37] anyone good with man macros; .BR -m, --host \fI HOST doesn't seem to want to render a space before HOST [05:38] I tend to just quote things [05:41] that's still getting me -m,--hostHOST [05:43] .BR -m ", " --host \fIHOST [05:43] ? [05:44] yeh but it's the space after '--host' I can't get to happen [05:44] let me try a " " [05:44] "--host " ? :p [05:44] yeh that's done it [05:45] typesetter being too smart for its own good :-) [06:19] ok, #117215 === Keybuk [n=scott@wing-commander.netsplit.com] has joined #upstart [12:15] I learned a new word from Futurama: oughtnt :-D [12:17] i learned "unpossible".... i don't think that's a real word tho [12:21] heh