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