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