[00:00] <sadmac> Keybuk: and it "belongs" in /usr/apache/conf if upstream has their sya
[00:00] <sadmac> *say
[00:00] <Keybuk> oh, that's right, you guys rename it for some inexplicable reason
[00:00] <sadmac> Keybuk: so do you.
[00:01] <Keybuk> we call it apache2
[00:01] <sadmac> yep. Its not supposed to be.
[00:01] <sadmac> its supposed to just be apache, and (scarier) its not supposed to be in etc
[00:01] <Keybuk> ok, true, it should be apache
[00:01] <Keybuk> but apache is apache 1.x
[00:02] <sadmac> Keybuk: the plot thickens...
[00:02] <sadmac> Keybuk: at any rate, its already getting ugly this idea of distro-compatible scripts
[00:03] <sadmac> Keybuk: if you force them to be in one file, you are going to see people do things with sed that you can't unsee
[00:03] <sadmac> in package post-install scripts
[00:04] <mbiebl> sadmac: I think simple/trivial scripts could surely be cross-distro
[00:04] <mbiebl> acipd, smartd, 
[00:04] <mbiebl> atd ...
[00:05] <sadmac> mbiebl: well they're welcome to, but we aren't talking about simple, trival scripts. We're talking about /all/ scripts
[00:05] <sadmac> this is blanket policy
[00:05] <Keybuk> things have to be upstream
[00:05] <Keybuk> because if they're not upstream, then we have to maintain them as a divergence from Debian
[00:05] <Keybuk> and that hurts
[00:05] <Keybuk> if they're uniform, then upstream can put them in the tarball
[00:05] <Keybuk> and Debian takes Upstart through the back door
[00:06] <sadmac> someone's going to be taking it through the back door alright :)
[00:06] <sadmac> I don't think it will happen
[00:07] <sadmac> even still, I think the python syntax will make more sense anyway with the new state machine
[00:07] <Keybuk> depends
[00:07] <Keybuk> I actually have a vague theory about being able to specify multiple things in one file
[00:08] <Keybuk> like if you're defining apache, you should be able to put the daily log rotation job in there too
[00:08] <Keybuk> so one bit defines the daemon, then you define a different while/on clause, with a different task/service attached
[00:08] <sadmac> Keybuk: the way it is now, you could have:
[00:08] <sadmac> foostate(bar: baz):
[00:08] <sadmac>     when something
[00:08] <sadmac> foostate(bar: bang):
[00:08] <sadmac>     when something else
[00:09] <sadmac> Keybuk: and those conf items could apply to two different states /or both apply to the same state/
[00:09] <sadmac> Keybuk: foostate(bar: baz) will get the first when, foostate(bar: bang) gets the second, foostate(bar: baz, bar: bang) gets both
[00:10] <ion_> Real-life examples would be so much nicer. :-)
[00:11] <sadmac> ion_: there's actually a good IRL one in the blog posts for this particular case
[00:11] <sadmac> mount(...):
[00:11] <sadmac>     (mount stuff here)
[00:11] <sadmac> mount(type: nfs, ...):
[00:11] <sadmac>     when network
[00:11] <sadmac> mount(type: somefusefilesystem, ...):
[00:11] <sadmac>     (non-standard mount command used)
[00:12] <ion_> Much better. :-)
[00:12] <sadmac> the stuff under the first mount line applies to /all/ mounts.
[00:12] <sadmac> the latter two apply only to mounts of a particular filesystem type
[00:15] <Keybuk> though that optimises the uncommon case again
[00:16] <sadmac> Keybuk: its not terribly expensive
[00:17] <Keybuk> assert ( cost == 0 );
[00:17] <sadmac> Keybuk: the reason I allow the state machine to behave this way is because it would cost me extra effort not to. I'd have to explicitly state it was impossible.
[00:17] <sadmac> cost < 0
[00:17] <Keybuk> err
[00:17] <Keybuk> I only care about the cost to a user
[00:18] <Keybuk> like I said, we're writing an init daemon here
[00:18] <Keybuk> not a math paper
[00:18] <sadmac> in terms of implementation details its easier to write
[00:18] <Keybuk> if the implementation is harder, but gives a better user experience, I'd rather go with the harder implementation
[00:18] <sadmac> I see this only as a gain
[00:19] <sadmac> I see no disadvantage other than semantics of files, which I have no interest in preserving
[00:19] <Keybuk> it makes the files harder to understand
[00:19] <Keybuk> you need to know more about what's going on under the hood
[00:19] <Keybuk> you can't just do
[00:20] <Keybuk> cat > /etc/init/some_service
[00:20] <Keybuk> while ...
[00:20] <sadmac> It looks pretty obvious to me
[00:20] <Keybuk> exec ...
[00:20] <Keybuk> ^D
[00:20] <sadmac> this is what you do to mount a filesystem
[00:20] <sadmac> this is what's different if its nfs
[00:20] <sadmac> this is what's different if its a funky filesystem
[00:20] <Keybuk> but it isn't obvious
[00:20] <Keybuk> what the hell is the stuff before the :
[00:20] <Keybuk> is that the while clause?
[00:20] <sadmac> name of state, arguments to state
[00:20] <Keybuk> while ...:
[00:20] <Keybuk>   ...
[00:20] <Keybuk> exactly, you suddenly force everyone to define a state to define a service
[00:21] <Keybuk> I don't like that
[00:21] <sadmac> if jobs /are/ states, that's kind of inherent
[00:26] <Keybuk> let's use a simple example then
[00:26] <Keybuk> how would you define the job for the dbus session bus daemon?
[00:26] <sadmac> dbus_session_daemon(%session):
[00:27] <Keybuk> it runs for each instance of the x-session state
[00:27] <sadmac>     when x-session(id: %session)
[00:27] <sadmac>     auto
[00:27] <sadmac>     exec /usr/bin/dbus-session
[00:27] <Keybuk> ok
[00:28] <Keybuk> instead of exec, use eval - that puts the $DBUS_SESSION_BUS_ADDRESS into the job's environment
[00:28] <Keybuk> that environment variable is required for anything that depends on dbus_session_daemon
[00:28] <Keybuk> modify the definition, and show a job that depends on dbus_session_daemon and gets that address
[00:28] <sadmac> dbus_session_daemon(%session):
[00:28] <sadmac>     when x-session(id:....
[00:28] <Keybuk> no ...s :p
[00:29] <sadmac>  /* blah blah, skip to last line*/
[00:29] <sadmac> ok
[00:29] <sadmac> dbus_session_daemon(%session):
[00:29] <sadmac>     when x-session(id: %session)
[00:29] <sadmac>     auto
[00:29] <sadmac>     eval DBUS_SESSION_BUS_ADDRESS=%session /usr/bin/dbus-session
[00:30] <Keybuk> I don't understand your eval line there, could you explain it?
[00:30] <sadmac> it substitutes %session for the session argument
[00:31] <Keybuk> err, but DBUS_SESSION_BUS_ADDRESS is printed *by* dbus-session
[00:31] <Keybuk> that was my point
[00:31] <Keybuk> you run dbus-session, grab its stdout, and you get something that looks like an envvar
[00:31] <sadmac> ah, I misunderstood the question
[00:31] <Keybuk> interestingly, your model is like 0.5 in its treatment of instances
[00:31] <Keybuk> in that you have to explicitly define what makes a job unique
[00:31] <Keybuk> in your case there, you have to say that it's unique per value of %session
[00:31] <Keybuk> I assume that if you try and start one, you have to give a value for %session
[00:32] <Keybuk> I'm guessing that:
[00:32] <Keybuk> singleton():
[00:32] <sadmac> Keybuk: if you start it manually yes
[00:32] <Keybuk>   exec foo
[00:32] <Keybuk> can only be run once?
[00:32] <Keybuk> you can't start multiple copies
[00:32] <sadmac> no
[00:32] <Keybuk> no you can't, or no you can?
[00:33] <sadmac> you can't
[00:34] <sadmac> you could do something like:
[00:34] <sadmac> singleton(%_nonce_):
[00:34] <sadmac>     exec foo
[00:34] <sadmac> where nonce would be some unique ID that would be filled in for you.
[00:34] <Keybuk> ok
[00:34] <Keybuk> so let's say you wanted to run a service in a chroot
[00:34] <Keybuk> or a group of services
[00:35] <Keybuk> you'd have to add %chroot to everything?
[00:35] <sadmac> depends.
[00:35] <sadmac> if they all run in the same chroot then definitely no
[00:35] <Keybuk> why no?
[00:35] <Keybuk> I mean have a second copy of everything across two chroots
[00:36] <Keybuk> for the record, btw, my equivalent would look like:
[00:36] <Keybuk> while x-session
[00:36] <Keybuk> eval /usr/bin/dbus-launch --sh-syntax
[00:36] <Keybuk> export DBUS_SESSION_BUS_ADDRESS
[00:36] <Keybuk> while dbus-session-bus
[00:36] <Keybuk> exec /usr/bin/dbus-session-service
[00:36] <Keybuk> err
[00:36] <Keybuk> while x-session
[00:36] <Keybuk> eval /usr/bin/dbus-launch --sh-syntax
[00:36] <Keybuk> export DBUS_SESSION_BUS_ADDRESS
[00:36] <Keybuk> --
[00:36] <Keybuk> while dbus-session-bus
[00:36] <Keybuk> exec /usr/bin/dbus-session-service
[00:36] <Keybuk> --
[00:36] <Keybuk> gap between the two jobs got lost there :p
[00:37] <sadmac> you have to define 2 states?
[00:37] <Keybuk> one for the dbus session bus
[00:37] <Keybuk> the other for the service you want to run on it
[00:37] <Keybuk> they're services, not states, in my model
[00:37] <sadmac> oh
[00:38] <sadmac> right
[00:38] <sadmac> ok, seeing that I can answer your question
[00:38] <sadmac>     when x-session(id: %session)
[00:38] <sadmac> wait...
[00:39] <sadmac> dbus_session_daemon(%session):
[00:39] <sadmac>     when x-session(id: %session)
[00:39] <sadmac> shit. too quick on the copypasta
[00:39] <sadmac> dbus_session_daemon(%session, %busaddr):
[00:39] <sadmac>     when x-session(id: %session)
[00:39] <sadmac>     auto
[00:40] <sadmac>     busaddr := exec /usr/bin/dbus-launch --sh-syntax
[00:41] <sadmac> dbus_session_service(%busaddr):
[00:41] <sadmac>     when dbus_session_daemon(%busaddr)
[00:41] <sadmac>     auto
[00:42] <sadmac>     exec DBUS_SESSION_BUS_ADDRESS=%busaddr /usr/bin/dbus-session-service
[00:42] <Keybuk> I think my way is easier :)
[00:43] <sadmac> I don't
[00:44] <ion_> In this case, Keybuk’s syntax wins.
[00:44] <sadmac> ok
[00:44] <sadmac> Keybuk: how do you express the mounting case?
[00:46] <Keybuk> there's not enough info in yours to tell
[00:46] <Keybuk> could you expand yours a little
[00:47] <sadmac> let me flesh them out
[00:47] <sadmac> mount(%mountpoint):
[00:47] <sadmac>     when file-exists(%mountpoint)
[00:48] <sadmac> damn!
[00:48]  * sadmac needs an irc line editor
[00:49] <Keybuk> I just use vi and paste ;)
[00:49] <sadmac> yeah, doing that way now
[00:51] <sadmac> mount(%mountpoint, %devname): when file-exists(%mountpoint) exec mount %devname %mountpoint
[00:51] <sadmac> mount(auto: true): auto
[00:51] <sadmac> wow. fail
[00:51] <sadmac> mount(type: nfs): when network()
[00:51] <sadmac> mount(type: ntfs, %mountpoint, %devname): exec ntfs3g-mount %mountpoint, %devname
[00:51] <sadmac> ok, that, but with linebreaks
[00:52] <sadmac> mount(%mountpoint, %devname): when file-exists(%mountpoint) exec mount %devname %mountpoint
[00:52] <sadmac> mount(auto: true): auto
[00:52] <sadmac> mount(type: nfs): when network()
[00:52] <sadmac> mount(type: ntfs, %mountpoint, %devname): exec ntfs3g-mount %mountpoint, %devname
[00:52]  * sadmac goes to file a bug against IRSSI
[00:52] <Keybuk> hmm
[00:52] <sadmac> I'll pastebin it then
[00:52] <Keybuk> surely that's wrong
[00:52] <Keybuk> according to your own blog
[00:52] <Keybuk> mount(type: nfs): ...
[00:53] <Keybuk> simply creates a state where type = nfs
[00:53] <Keybuk> it doesn't bind that to any dependant states
[00:53] <Keybuk> what you mean is
[00:53] <sadmac> Keybuk: no
[00:53] <Keybuk> mount(%type):
[00:53] <Keybuk>   when ... type=nfs ?
[00:53] <sadmac> Keybuk: no
[00:53] <Keybuk> no?
[00:54] <sadmac> mount(type: nfs) means that the below config items apply to all mount states such that type = nfs
[00:54] <sadmac> Keybuk: and you never create states in my model
[00:54] <sadmac> Keybuk: you just say when they'll be on
[00:55] <Keybuk> oh, I see
[00:55] <sadmac> Keybuk: the syntax on my blog was designed to facillitate mathiness. It won't always resemble this
[00:56] <Keybuk> err
[00:56] <Keybuk> so each ...(): is like a while clause?
[00:56] <Keybuk> so
[00:56] <Keybuk> dbus_session_daemon(%session):
[00:56] <Keybuk>   ...
[00:56] <Keybuk> defines both the dbus session daemon
[00:56] <Keybuk> *and*
[00:56] <Keybuk> something that depends on the dbus session daemon?
[00:56] <Keybuk> to simplify
[00:57] <Keybuk> I want food to run
[00:57] <Keybuk> (heh)
[00:57] <Keybuk> foo(...):
[00:57] <Keybuk>    exec /usr/sbin/food
[00:57] <Keybuk> now I want bard to run along side that
[00:57] <Keybuk> I could either do
[00:57] <Keybuk> bar(...):
[00:57] <Keybuk>    when foo
[00:57] <Keybuk>    exec /usr/sbin/bard
[00:57] <Keybuk> or
[00:57] <Keybuk> foo(...)
[00:57] <Keybuk>    exec /usr/sbin/bard
[00:58] <sadmac> Keybuk: those are slightly different in one way. notice how I kept the auto keyword?
[00:58] <Keybuk> yes, I didn't get that
[00:58] <sadmac> Keybuk: in your first writing, it is possible to bring up foo, then bring up bar, but bringing up bar will always bring up foo.
[00:58] <Keybuk> right
[00:59] <Keybuk> but it means there's two different ways to make one job run with another
[00:59] <sadmac> Keybuk: in your second example, both executables shadow the same state, so they are completely non-independant
[00:59] <sadmac> Keybuk: the second is a bad idea
[00:59] <Keybuk> I'd place a bet now that the second is what most people will write ;)
[00:59] <Keybuk> in fact
[00:59] <Keybuk> I'd bet you that what most people will write is:
[00:59] <Keybuk> runlevel2(...):
[00:59] <Keybuk>    exec my daemon
[01:00] <sadmac> Keybuk: let me translate my dbus one into english
[01:01] <sadmac> dbus_session_daemon(%session, %busaddr):         // For a state dbus_session_daemon with arguments session and busaddr of any value
[01:01] <Keybuk> oh, I think I actually understand how your model works now :)
[01:01] <Keybuk> it's quite neat
[01:01] <sadmac> ok.
[01:02] <sadmac> let me stop there, because I might confuse you again :)
[01:02] <sadmac> tell me what you've found
[01:02] <Keybuk> you define states
[01:02] <Keybuk> and you define things to be done when a given state is true
[01:02] <Keybuk> "jobs" are the latter
[01:02] <Keybuk> the former are done by things like initctl I guess
[01:02] <Keybuk> so your fstab example works because you define states for the items in fstab
[01:02] <Keybuk> and the jobs defined items that are processed when those things are true
[01:03] <Keybuk> foo(...):
[01:03] <Keybuk>    exec foo
[01:03] <Keybuk> foo(...):
[01:03] <Keybuk>   when ...
[01:03] <Keybuk>   exec bar
[01:03] <Keybuk> actually adds the when to both?
[01:03] <Keybuk> the when introduces the dep to foo, not to the short clip of things-to-be-done-when-foo-is-true, right?
[01:03] <sadmac> assuming the (...) is the same for both
[01:03] <sadmac> right
[01:04] <ion_> pe025244  * sadmac goes to file a bug against IRSSI
[01:04] <sadmac> ion_: yeah, I should go do that
[01:04] <ion_> How about turning paste_join_multiline off?
[01:04] <sadmac> ion_: good idea!
[01:05] <Keybuk> I think the problem you're going to have is explaining your model in such a way that people don't do
[01:05] <Keybuk> runlevel2():
[01:05] <Keybuk>    exec my_service
[01:05] <Keybuk> because the simplest paragraph
[01:05] <Keybuk> "BLAH: exec..." defines a service to be run while the BLAH state is true
[01:06] <Keybuk> is going to tell people to do exactly that
[01:07] <sadmac> Keybuk: there is some issue there, and some of it can be fixed with more syntax, but fortunately you and I will control most of the initial usage of this :) I think that once my terse and formal self is out of the room and you open up a system defined this way and actually look at the examples it will become clear
[01:08] <sadmac> Keybuk: in the long run I don't think its terribly difficult for a sysadmin to do, even if the short term might include a bump or two. It should become natural over time.
[01:08] <sadmac> I like about this one that common sense does work quite a bit better for it than for many other models I've played with.
[01:09] <Keybuk> I'd be interested to see if you could write an example page of the "writing a service" documentation
[01:09]  * Keybuk likes writing end-user documentation as a design method
[01:09] <sadmac> I could do that.
[01:11] <sadmac> Keybuk: one of the big goals here was actually to be mathematically rigorous, and for a good reason. We're doing this rewrite because we kept finding out things about the previous mechanism that hadn't occured to us.
[01:11] <sadmac> It may be an up hill battle explaining the minutiae of this thing, but no one will /EVER/ tell me something about it that surprises me. Its definition is thorough and complete.
[01:24] <sadmac> notting: you missed Keybuk suddenly understanding what I've been yammering about for the past 2 months :)
[20:21] <geiseri_> hey, how do i change the order of things in the event.d directory, i am on intrepid and my event broke because it needs to wait for hal to start.
[20:29] <geiseri_> on started hal  <- is this what i should have there?
[20:30] <geiseri_> if hal is the rc.d step?