[00:04] <ion_> Alright
[00:07] <Keybuk> which seems reasonable
[01:24] <sadmac> Keybuk: still looking for a new name for the "on" stanza?
[01:30] <Keybuk> sadmac: potentially
[01:31] <sadmac> Keybuk: I was thinking "when"
[01:31] <Keybuk> and what would be the opposite?
[01:31] <sadmac> Keybuk: when not?
[01:32] <Keybuk> that's a bit ... odd :)
[01:32] <Keybuk> especially since the following bits would be true :P
[01:32] <Keybuk>   when started gdm
[01:32] <Keybuk>   when not stopping gdm
[01:32] <Keybuk> (except it's stopped *when* stopping gdm)
[01:32] <sadmac> Oh, I thought on syntax did that all in one stanza
[01:32] <sadmac> when started gdm until stopping gdm
[01:33] <sadmac> but on that note, unti'
[01:33] <sadmac> s/unti'/until/
[01:33] <Keybuk> that syntax got dropped a while back
[01:33] <Keybuk> the "until" operator's semantics got crazy
[01:33] <sadmac> ah
[01:35] <Keybuk> current front-runner is three stanzas
[01:35] <Keybuk> "from" (morally equivalent to "start on")
[01:35] <Keybuk> "until" (morally equivalent to "stop on")
[01:36] <Keybuk> "when" (state matching)
[01:36] <Keybuk> so, something like
[01:36] <Keybuk>   from tty-added
[01:36] <Keybuk>   until tty-removed $TTY
[01:36] <Keybuk>   while multiuser
[01:36] <Keybuk> (err, s/"when"/"while"/ :p)
[01:37] <sadmac> so can you pair them explicitly?
[01:37] <Keybuk> I think so
[01:38] <sadmac> from a \n until b \n from c \n until d   Where if it starts on a it won't stop on d
[01:38] <Keybuk> no
[01:38] <Keybuk> you can't do that
[01:38] <sadmac> hmm
[01:38] <sadmac> how do the multi-instance jobs work then?
[01:39] <sadmac> I guess that's more environment though
[01:39] <Keybuk> example?
[01:39] <sadmac> from some_tty starts
[01:39] <sadmac> until that_specific_tty_that_started_me_stops
[01:40] <Keybuk> right
[01:40] <Keybuk> so you'd match that using environment
[01:40] <Keybuk> from tty-up
[01:40] <Keybuk> until tty-down $TTY
[01:40] <Keybuk> the tty-up event carries TTY=tty1 as an environment payload
[01:40] <Keybuk> that gets added to the jobs own environment while it's running
[01:41] <Keybuk> (in fact, for getty, that would probably be the way unique instances are determined)
[01:41] <Keybuk> because it will be in the environment of the job, the job can match against it in its own definitions
[01:41] <Keybuk> so thus:
[01:41] <Keybuk>   until tty-down $TTY
[01:41] <sadmac> I also wanted to know how you have jobs become able to be started on events without starting them
[01:41] <sadmac> I.e. `start job_x` fails
[01:42] <sadmac> I plug in a smart card, nothing results directly from this
[01:42] <sadmac> but while the smart card is in, `start job_x` succeeds
[01:43] <sadmac> so basically "this job can only be run while in state X, but it doesn't have to be running in said state"
[01:44] <Keybuk> means match the TTY variable from the tty-down event to the $TTY variable in the job
[01:45] <Keybuk> you'd use states for that, maybe
[01:46] <Keybuk> I'm not sure how much preventing the sysadmin from doing stuff we want to do
[01:46] <Keybuk> I think I'm generally inclined to think if a sysadmin tries to start job_x, even while there's no smart card in, it should let them
[01:46] <Keybuk> and obviously job_x will fail and give them meaningful error messages
[01:47] <Keybuk> (ie. the daemon started will fail)
[01:47] <sadmac> true
[01:48] <Keybuk> obviously Upstart should never attempt to start it automatically
[01:49] <sadmac> cool
[01:49] <Keybuk> a more interesting question is if you start a job manually, should Upstart ever stop it automatically? :)
[01:50] <sadmac> This does bring up a point about the flags/profiles things. Usually we want to prevent a service from coming up automatically, but if after loading the profile the admin decides to start one manually himself, we should let him
[01:51] <Keybuk> right
[01:53] <sadmac> Ok, might be more of a unix API question, unless nih has something I don't know about, but how would I change upstart init's tty from within the source code?
[01:53] <Keybuk> how do you mean?
[01:54] <sadmac> Like make nih_info/error/whatever and the stdout of 'console output' services route to /dev/some/specific/tty
[01:55] <Keybuk> easiest way would be just to change upstart's own console
[01:55] <Keybuk> ie in init/main.c
[01:56] <sadmac> yeah, having trouble getting unix to do that for me.
[01:56] <Keybuk> don't you just change it? :p
[01:56] <sadmac> Right now I'm sending TIOCNOTTY to /dev/tty, and then open()ing the new tty, which should do it.
[01:56] <Keybuk> do you even *have* /dev/tty at that point? :)
[01:56] <Keybuk> on a udev-based system, you only generally have /dev/console and maybe /dev/null when init starts
[01:57] <sadmac> hmm.
[01:57] <sadmac> I should add that I want this to happen dynamically, and to revert the change later (I've got the revert thing figured out, if I can just change it in the first place)
[01:57] <Keybuk> without knowing much more about Fedora, I'm not sure I can help :-/
[01:58] <Keybuk> certainly on Ubuntu, nothing other than /dev/console exists when init starts
[01:59] <sadmac> well my current technique isn't working even when I'm testing it (well after udev starts)
[01:59] <Keybuk> what's taht?
[01:59] <sadmac> after the TIOCNOTTY and the change, its still logging to the same place
[02:00] <Keybuk> that could be syslog() doing that
[02:00] <sadmac> basically I have an initctl push_tty /dev/something and an initctl pop_tty command. They appear to work, but logging behavior doesn't actually change.
[02:01] <Keybuk> upstart's own log output?
[02:01] <Keybuk> or the output of jobs?
[02:01] <sadmac> upstart's own
[02:01] <Keybuk> that's probably syslog doing that then
[02:02] <sadmac> ahh, so nih_info outputs to syslog?
[02:02] <Keybuk> does commenting out the openlog() and nih_log_set_logger() calls help?
[02:02] <Keybuk> (then it'll just use printf)
[02:03] <sadmac> I'll try that
[02:03] <sadmac> In fact I should set up a test job to do things with actual job output
[10:36]  * Keybuk yawns
[10:37] <Keybuk> too damned windy again today
[20:37] <Keybuk> dear valgrind, please exit 1 if you find an error, kthxbye
[20:37] <ion_> Heh
[20:45] <Keybuk> hurrah
[20:45] <Keybuk> job->start_on is no more
[20:46] <Keybuk> start and the resulting environment are now atomic
[20:47] <Keybuk> so if you "start getty TTY=1"
[20:47] <Keybuk> and then do "stop --id 123; start --id 123 TTY=2"
[20:47] <Keybuk> the stop scripts will still have $TTY=1
[20:47] <Keybuk> and won't get $TTY=2 until it restarts
[20:50] <ion_> Neat.
[20:54] <Keybuk> do you think it matters why a job is stopped?
[20:55] <Keybuk> I'm thinking of only making the stop event environment available to the pre-stop script
[20:55] <Keybuk> since that script can decide to start the job again without killing the running process
[20:55] <Keybuk> I don't think post-stop should get the environment, since it shouldn't care ?
[20:55] <ion_> Mm... I can’t think of any use cases immediately.
[20:56] <ion_> A post-stop script might e.g. want to send email based on the job’s exit value, or something.
[21:01] <Keybuk> it should do that by hooking the stopped event ;)
[21:01] <ion_> Good point. :-)
[21:08] <Keybuk> let me dump my thoughts here
[21:08] <Keybuk>   start on foo or bar
[21:08] <Keybuk>   stop on wibble or wibble
[21:09] <Keybuk>   ... some job
[21:09] <Keybuk> initctl emit foo
[21:09] <Keybuk> job goal changed from stop to start
[21:09] <Keybuk> job state changed from waiting to starting
[21:10] <Keybuk> job state changed from starting to pre-start
[21:10] <Keybuk>   (pre-start run with UPSTART_EVENTS=foo)
[21:10] <Keybuk> job state changed from pre-start to spawned
[21:10] <Keybuk>   (main process with UPSTART_EVENTS=foo)
[21:10] <Keybuk> job state changed from pre-start to post-stop
[21:10] <Keybuk> (err, start)
[21:10] <Keybuk> job state changed from post-start to running
[21:10] <Keybuk> ok
[21:10] <Keybuk> so the job is running, and the environment remained the same
[21:10] <Keybuk> now do
[21:11] <Keybuk> initctl emit wibble
[21:11] <Keybuk> job state changed from running to pre-stop
[21:11] <Keybuk>   (pre-stop run with UPSTART_STOP_EVENTS=wibble)
[21:11] <Keybuk> job state changed from pre-stop to stopping
[21:11] <Keybuk> now:
[21:11] <Keybuk> initctl emit bar
[21:11] <Keybuk> job goal changed from start to stop
[21:11] <Keybuk> initctl emit wobble
[21:11] <ion_> Don’t you mean from stop to start?
[21:12] <Keybuk> yes, sorry
[21:12] <Keybuk> missed a line :p
[21:12] <Keybuk> job goal changed from start to stop
[21:12] <Keybuk> we're still in the right line here, we were just blocking on our stopping event
[21:12] <Keybuk> so we're going to continue towards death
[21:12] <Keybuk> job state changed from stopping to killed
[21:12] <Keybuk>   (kill the main process)
[21:12] <Keybuk> job state changed from killed to post-stop
[21:12] <Keybuk>   (post-run run with UPSTART_STOP_EVENTS= ... errr...)
[21:12] <Keybuk> ie.
[21:12] <Keybuk> if we attempt to run the post-stop with the environment from the stop events, that will be "wobble"
[21:13] <Keybuk> yet pre-stop was run with "wibble"
[21:13] <ion_> Yep...
[21:13] <Keybuk> which is wrong :)
[21:13] <Keybuk> if script A, B and C are run with one set of environmen
[21:13] <Keybuk> so should script D
[21:13] <ion_> Yep
[21:14] <Keybuk> the reason we don't have this problem on start events is because we can always run through stop first
[21:14] <Keybuk> so we have the notion of the "next" start environment
[21:14] <Keybuk> wherever we are in the cycle, we can skip running and run through the whole thing again, and switch over the environment next time we pass through starting
[21:14] <Keybuk> this isn't bad, since it appears like a restart, which given a stop/start sequence is exactly what you'd expect
[21:15] <Keybuk> for stop, we don't really want to run through start again, just so we can stop it again :)
[21:15] <Keybuk> especially if we know the stop event/state/etc. has already happened
[21:15] <ion_> Aye
[21:15] <Keybuk> so that's my rationale for why only pre-stop should see the environment of the stop events
[21:16] <ion_> I don’t see a reason to disagree.
[21:16] <Keybuk> in a sensible job, the stop events should be balanced by the start events
[21:17] <Keybuk> so if you have tty-added...tty-removed as a pair, you can see tty-added in the post-stop script so assume that it was tty-removed that caused you to be stopped