[16:25:39]  <h_lfline_> woah i have underscores
   [16:26:10]  <sadmac2> h_lfline_: you're loosing vowels rapidly
   [16:26:10]  <h_lfline_> anyway, noticed a typo
   [16:26:40]  <h_lfline_> if [ -f /etc/init/$base.conf ]
   [16:26:51]  <h_lfline_> should probably be /etc/event.d/$base.conf
   [16:27:04]  <h_lfline_> but i wonder if that's the most "upstarty" way to
   do it
   [16:27:17]  <notting> /etc/init is the 0.6.x path
   [16:27:21]  <notting> /etc/event.d is the 0.3.x path
   [16:27:26]  <h_lfline_> ohhhhhh
   [16:27:28]  <h_lfline_> makes sense
   [16:27:42]  <sadmac2> h_lfline_: this should probably be in fedora-devel
   really. We've been coming down on the ubuntu questions pretty hard, so for
   fairness sake I should mention it.
   [16:27:59]  <notting> the problem is that if multiple DMs have installed
   jobs, you need to explicitly start one; you can't have them all start on a
   generic event
   [16:28:58]  <h_lfline_> but say you had a dm event
   [16:29:04]  <h_lfline_> with a DM variable
   [16:29:22]  <h_lfline_> then the only two competing would be the relevant
   dm and the fallback task
   [16:29:46]  <h_lfline_> sadmac2: oh i brought discussion here in case
   keybuk was around
   [16:30:24]  <h_lfline_> you guys probably know the internals of upstart a
   lot better than i do though
   [16:30:26]  <sadmac2> h_lfline_: there is that. anyway its venturing into
   more generic upstart stuff anyway
   [16:30:51]  <h_lfline_> notting: so i wonder if we could have the fallback
   task sit back and wait
   [16:31:04]  <h_lfline_> and only chime in if the main event doesn't show
   up
   [16:31:40]  <notting> that sounds messy to code
   [16:32:14]  <h_lfline_> i'm looking at this state diagram that's in the
   upstart tree
   [16:32:34]  <h_lfline_> and it looks like things shoot to stopping if
   nothing is around
   [16:33:14]  <h_lfline_> so maybe we could have a handler on stopping that
   checks if runlevel is still 5
   [16:33:27]  <h_lfline_> and if so starts fallback
   [16:34:13]  <h_lfline_> unless there's some upstart mechanism for "no one
   caught the event"
   [16:34:17]  <sadmac2> h_lfline_: Is this absolutely necessary?
   [16:34:31]  <h_lfline_> no absolutely not
   [16:34:50]  <h_lfline_> just trying to come up with the most upstart-y way
   of doing things
   [16:35:10]  <h_lfline_> if doing [ -f /etc/init/$base.conf ] && start
   $base is the right way to go
   [16:35:14]  <h_lfline_> then that's fine with me
   [16:35:45]  <notting> backing up, the idea we're trying to solve
   [16:35:52]  <notting> we pick a $foo to start
   [16:36:11]  <notting> we want to start a specific provided-by-$foo job if
   it exists; if not, start a generic job that starts $foo
   [16:36:33]  <notting> hence the logic abov
   [16:37:19]  <sadmac2> oh I see. hmm...
   [16:38:57]  <sadmac2> notting: the way I'd do it would be to have the
   fallback job check if the provided-by-$foo job has already started, and if
   so, terminate itself. Then the special foo job should start on starting
   generic-job
   [16:39:01]  <h_lfline_> so the question is, do we detect if a job doesn't
   exist by doing if [ ! -f /etc/init.d/$job.conf ] or is there some upstart
   hook to say "only call me if for this event if no one else takes it"
   [16:39:43]  <notting> sadmac2: that would mean the fallback would need to
   know all possible names of provided-by-$foo. sounds painful
   [16:39:44]  <h_lfline_> sadmac2: is there a way to ensure job ordering?
   [16:40:35]  <h_lfline_> ohhh start on starting is the way you keep order
   [16:40:39]  <sadmac2> notting: not really
   [16:41:16]  <notting^ how do you know what to check for otherwise?
   [16:41:18]  <sadmac2^ what you would do is have all of the
   provided-by-$foo jobs start another job called dm-started
   DISPLAY=$whatever. That job would have no executable. Its a "state" if you
   will
   [16:42:02]  <sadmac2> then you detect the presence of that (initctl list)
   to determine if the display manager is up
   [16:42:14]  <sadmac2> thereby implementing a good chunk of upstart 1.0 in
   userspace in bash :)
   [16:42:46]  <h_lfline_> you mean "initctl status dm-started "
   [16:42:48]  <h_lfline_> ?
   [16:42:50]  <notting> sounds messy
   [16:44:30]  <sadmac2^ its one line in each of the generic jobs (
   post-start start dm-started ) and really not much in the generic job
   [16:44:42]  <sadmac2> *one line in each of the specific jobs
   [16:45:09]  <notting> so you'd have specific job: 'start on start-dm
   DM=foo', and then 'post-start initctl emit started-dm'
   [16:45:31]  <notting> and the generic job has 'start on start-dm', 'stop
   on started-dm'. with a sleep thrown in?
   [16:45:32]  <h_lfline_> start on starting start-dm DM=foo
   [16:45:52]  <sadmac2> notting: the specific job would have start on
   starting generic-dm-job DM=foo
   [16:45:59]  <h_lfline_> i think sadmac was saying if you put the
   "starting" then you don't need a sleep
   [16:46:13]  ***  plndra is now known as plundra.
   [16:46:27]  <sadmac2> notting: the idea is we always just try to run the
   generic job, and then we just have the specific jobs jump in the way and
   say "wait!"
   [16:47:14]  <notting> 'bar: start on starting foo' implies bar must finish
   before foo starts?
   [16:48:20]  <sadmac2^ yes.
   [16:48:52]  <sadmac2> when jobs emit events they wait for all the
   responders to finish responding before they continue. Its a very important
   part of how upstart works.
   [16:49:20]  * notting goes off to write the 'start on starting startup'
   job
   [16:49:36]  <sadmac2^ and actually you don't need the dm-started state.
   you could have the specific jobs just have "post-start stop generic-job"
   [16:49:45]  <sadmac2> and then the generic job will never get past
   starting.
   [16:50:05]  <h_lfline_> oh that's a littler nicer
   [16:50:19]  <h_lfline_> so you have start on starting display-manager
   DM=gdm
   [16:50:37]  <sadmac2> notting: that has the advantage that the generic job
   can be written in a vacuum, with no knowledge that there is such a thing
   as a specific job or that it might run instead.
   [16:50:37]  <h_lfline_> psot-start stop display-manager
   [16:50:43]  <h_lfline_> hmm that doesn't sound right
   [16:50:53]  <h_lfline_> maybe it should be called display-manager-arbiter
   or something
   [16:50:54]  <sadmac2> h_lfline_: it doesn't but it is
   [16:51:03]  <sadmac2> yeah, name it as you like
   [16:51:05]  <notting^ although it does mean that the individual jobs need
   to know about the generic job
   [16:51:31]  <sadmac2^ indeed, but they'd have to know about some event or
   something that was going to kick them off anyway.
   [16:51:38]  <sadmac2> so they don't need to know more than usual.
   [16:51:52]  <notting^ not as written now, but as halfline says, it's a bit
   hackish
   [16:52:31]  <sadmac2^ I'm on my way home. I could stop by and look at what
   you have
   [16:52:39]  <notting> lemme bounce you the mail
   [16:52:42]  <sadmac2> by on my way home I mean about to grab my coat
   [16:52:50]  <notting> i have to head out in ~15 anyway
   [16:52:57]  <sadmac2> cool
   [16:54:22]  <h_lfline_> clearly it should be called
   "quest-to-find-a-display-manager"
   [16:54:39]  <h_lfline_> start on starting quest-to-find-a-display-manager
   [16:54:46]  <h_lfline_> post-start stop quest-to-find-a-display-manager
   [16:54:59]  <notting> h_lfline_: of course, this is ignoring the
   contortions where it figures out what it needs to start. ah, legacy
   installbases and config files
   [16:55:44]  <h_lfline_> yea i'm pretty sure there's not much we can do
   about those checks and heuristics