[19:53] Keybuk: Have we decided what kind of info pid 1 will provide? i.e. is it just a feed of signals and other happenings or is it a Start-Stopped-Failed-Restarting kind of abstraction? [19:53] probably the same basic signals we have today [19:54] starting (lower left edge) [19:54] started (upper left edge) [19:54] stopping (upper right edge) [19:54] stopped (lower right edge) [19:54] where stopping and stopped will include properties containing exit codes, signals, output, etc. [19:54] yes. that's good [19:55] that's more useful to people who want to use pid 1 directly without the state service [19:55] and it makes it easier to manage the state service itself [19:55] BTW I think pid 1 should handle respawning transparently [19:56] respawning is interesting [19:56] as to whether or not you go through the levels [19:57] it can be reflected in the state machine, but it means 3 states for a single job (one for running, one for trying to respawn, one for either of the above) [19:58] that's how I used to have it [19:58] but I couldn't find any reason for having that magic third state [19:58] at the end of the day, if you're depending on a service, and that service is restarted [19:58] most likely, you have to be restarted too [19:58] with deps, there could be a serious falldown if that happens [19:59] d-bus crashes [19:59] and gets respawned [19:59] whole system bounces [20:00] d-bus is not allowed to crash. especially if it's in the kernel [20:00] it has to bounce though [20:00] if d-bus crashes, we really do have to restart everything that depended on it [20:00] it might be scary behaviour, but it's correct [20:01] every time that gets brought up to the d-bus developers, they just say to punt. and well, if we put the system bus in the kernel and make it panic() on exit, that works around the issue [20:01] I don't think that's relevant though? [20:01] it's still a good example [20:02] if X crashes, we probably have to restart everything that depended on it [20:04] Keybuk: if the respawn is in the state machine its a good example of the case for transition actions [20:05] transition A => TryRestartA on failed($OUR_SERVICE_HANDLE) [20:52] Mmm... runtime type definition [20:52] * sadmac2 loves Ruby [21:20] Ruby for the win. [21:28] notting: what is the state of the kernelspace dbus? I was at the talk, but I hadn't slept much and was only intermittently conscious. [21:29] not really that close to done [21:29] hm [21:30] sort of a proof-of-concept [21:31] if (dbus in kernel) then me search other job [21:32] keesj: wth kind of programming language is that? Visual Caveman? [21:33] human2.0 [21:33] (based on lua) [21:34] oic [21:35] well perhaps it can beat sysfs and netlink. [21:38] Keybuk: I'm hitting the old question: User starts X, event says to stop it. We do ?? [21:41] and its more complicated than we think [21:41] stop on dont-particularly-feel-like-spending-resources-on-this // User probably takes precedence [21:42] stop on disk-we-were-using-just-up-and-vanished // User can probably shove it [21:53] nvm doing it wrong [21:53] event can't say to stop it? [21:53] we removed "stop on" [21:54] Keybuk: yes. Just realized that [21:54] the condition in which X is permitted to be running can become false [21:54] so obviously, it has to be stopped ;) [21:54] the user can only start it while that is true anyway [21:54] when I realised we'd solved that old issue, I cried [21:54] with joy [21:55] Keybuk: I think instead of 'until', we should just say that anywhere you can use a state name you can also say (a..b) where a and b are events [21:55] why is .. better than a keyword? [21:56] how does that work when a contains multiple parameters? [21:57] (a b c .. d) [21:57] why is ".." better than "until" ? [21:57] its better because its valid /anywhere/ a state is [21:57] when foo and (a .. b) on bar [21:57] when foo and (a until b) on bar [21:58] you can wordify it yes [21:58] but that is different than on a until b [21:58] was from a until b [21:58] you wrote on a until b on the whiteboard at one point [21:58] this is just syntax though [21:59] I'm more interested in how it works atm [21:59] true [22:02] Keybuk: issue with your assertion about the dependency: [22:02] wait... [22:03] * Keybuk sits down and starts singing about gold [22:03] ok [22:03] we're good [22:03] I need to teach my brain to trust previous results [22:04] after I implemented that instance hack for states in 0.5 I think I twice had to re-prove to myself that it would work [22:04] what was the issue? [22:04] what if the user starts service A, which auto-starts its dependency service B, and then the user tries to stop service B [22:06] then A would stop [22:06] yep [22:06] actually, a nice "WARNING: YOU ARE A MORON" might be nice. [22:08] Didn’t read the discussion yet, but such a warning is always nice. :-) [22:08] well, we could do quite interesting things [22:08] # stop apache [22:09] must also stop tomcat, continue? [y/n] [22:09] # stop -f apache [22:09] obviously we'd only do that if apache was making a depender's state false [22:09] if apache depended on tomcat, we wouldn't bug [22:11] So from what I have we have 3 reasons a service can start (An event the service listens for, Dependency, or User saying go) and 2 it can stop (lost dependency, User saying stop) [22:12] err four [22:12] what's 4? [22:12] dependant state becoming true, and auto [22:12] event while dependant state is true [22:13] depended on by another service while dependant state is true [22:13] user saying so while dependant state is true [22:14] Keybuk: reason 1 and 2 are the same in the current abstraction (You'll recall epsilon events?) [22:14] my terminal fails at unicode today or I'd use an actual epsilon [22:15] ɛ [22:15] there we go