[16:49] <sadmac2> Keybuk: In the new model, we remove "stop on" events, but I think it might be useful to have a "fail on" so that when pid 1 notifies the state machine that a process fell over we can reflect this as an event
[16:50] <Keybuk> ?
[16:51] <sadmac2> Keybuk: so where stop on says "stop this service when X happens" fail on would say "when X happens, the service is no longer running to to extenuating circumstances. Please update the state machine to reflect this"
[16:53] <sadmac2> we could even offer a script to run when this happens to cleanup any leftover post-crash bullshit (dead pidfiles, broken /var data, etc)\
[16:56] <Keybuk> what would be an example use?
[16:57] <sadmac2> Keybuk: for the fail on event in general? just about anything. We start apache, apache crashes, we find out about it by an event and drop the apache state without running its falling edge code.
[16:58] <Keybuk> but we don't
[16:58] <Keybuk> apache crashes directly affects the job
[16:58] <Keybuk> it's not an event
[16:59] <sadmac2> Keybuk: if we have a separate pid 1 service mananger and state machine, then we have to communicate the change somehow to cause that effect.
[16:59] <sadmac2> Keybuk: this is one way of doing that
[22:18] <arekm> hi, I'm trying to use mingetty with upstart but it fails with: /sbin/mingetty[4965]: tty1: no controlling tty: Operation not permitted
[22:18] <arekm> mingetty tries to do: ioctl (fd, TIOCSCTTY, (void *) 1) == -1
[22:18] <arekm> and is called just by: exec /sbin/mingetty --noclear tty1
[22:19] <arekm> upstart 0.5
[22:27] <arekm> hm, NEWS seems to be good source of info. Found "session leader" directive needed