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