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