[06:22] <Keybuk> yup
[06:22] <Keybuk> definitely
[06:22] <Keybuk> after much consideration
[06:22] <Keybuk> we want to replace tty* with a single instance job :)
[06:23] <AlexExtreme> what were the reasons for deciding that? (just curious)
[06:23] <Keybuk> it's just neater and more upstartish
[06:23] <AlexExtreme> fair enough :p
[06:24] <Keybuk> solves the "but I don't have ttyN" Xen problem
[06:24] <Keybuk> start a tty when you get the event for it, combined with other events
[06:24] <AlexExtreme> ah yeah
[06:25] <AlexExtreme> so you won't get an event from udev for all the other ttys when using xe
[06:25] <AlexExtreme> *Xen
[06:58] <Keybuk> this is actually a really interesting case
[06:58] <Keybuk> we have a pair of events from udev, ADD /class/tty/* -> REMOVE /class/tty*
[06:58] <Keybuk> between these, we know that /dev/* exists for a tty-class device
[06:59] <Keybuk> so we can say that a tty exists, and which tty that is
[07:05] <Keybuk> and we want the getty job "bound" to that
[07:05] <Keybuk> ie. each instance refers to one of the underlying devices, and has the information about those available
[07:05] <Keybuk> but that also needs to be intersected with another sequence of events
[07:06] <Keybuk> "the period during which a user can login"
[07:06] <Keybuk> this is a complex calculation based on things like /etc/nologin existing, ldap being running (for local ldap auth), nscd, nfs (home dirs), dirs being mounted, etc.
[07:10] <Keybuk> and I think that Upstart should be able to calculate this event itself, rather than farming it off to some other process?
[07:11] <AlexExtreme> yes
[07:14] <Keybuk> perhaps I need to take lots of mind-altering drugs, and sit in a tent on the beach with a nice fire going, until my spirit guide comes to me and tells me how to do that :p
[07:14] <ion_> :-)
[07:15] <AlexExtreme> :D
[07:22] <Keybuk> scheme interpreter? :p
[07:43] <JohnFlux> Keybuk: just out of interest, will kdm etc be able to ask for the password etc before the user is able to login
[07:44] <JohnFlux> Keybuk: since it takes a long time for the user to enter a password
[07:46] <ion_> (job 'tty1 ((start-on "runlevel [2-5] ") (stop-on "runlevel {0,1,6}") (respawn) (exec "/sbin/getty 38400 tty1")))
[08:25] <Keybuk> ion_: heh
[08:25] <Keybuk> ion_: I'd rather like the native jobs to not refer to the runlevels
[08:26] <ion_> Yeah, i just took a random file from my current /etc/event.d and converted it. :-)
[08:27] <Keybuk> JohnFlux: kdm can do whatever it likes ;)
[08:29] <Keybuk> ion_: the tricky thing is defining how events interact to form states
[08:29] <Keybuk> you'd probably want dynamic event interaction too
[08:30] <JohnFlux> btw I was looking at the upstart files
[08:30] <JohnFlux> it would be really nice to allow you to write     "start after stopping apache"  etc
[08:31] <Keybuk> ie. "depend on path-mounted ... path-unmounted /usr if getmntent -q -f -d /usr
[08:31] <JohnFlux> so  using "after" and "before" instead of "on"
[08:31] <Keybuk> JohnFlux: the whole start on/stop on thing is likely to be changing for 0.5
[08:31] <Keybuk> so the new language may be nicer
[08:31] <JohnFlux> "after stopping" and "before starting"  is much more readable than "on starting"
[08:31] <JohnFlux> oh okay
[08:31] <Keybuk> "after" has semantic meaning though
[08:31] <Keybuk> do "after starting apache" things get run after those things with "on starting apache", etc.
[08:34] <Keybuk> (and we also have planned temporal events, e.g. start 10m after starting apache")
[08:35] <ion_> start 1m before startup
[08:36] <Keybuk> ion_: a proposed implementation on my desk by 9am, please
[08:36] <Keybuk> ;)
[08:36] <ion_> :-)
[08:36] <Keybuk> (actually, that would be easy to implement -- you'd delay startup by 1m)
[08:36] <ion_> Hehe, yeah
[12:08] <dg> what's the recommended way to run something as a different user from an upstart script?
[12:13] <mbiebl> dg: upstart doesn't implement that functionality yet.
[12:13] <mbiebl> So you have to use "su"
[12:16] <dg> ah