| ion_ | Alright | 00:04 |
|---|---|---|
| Keybuk | which seems reasonable | 00:07 |
| sadmac | Keybuk: still looking for a new name for the "on" stanza? | 01:24 |
| Keybuk | sadmac: potentially | 01:30 |
| sadmac | Keybuk: I was thinking "when" | 01:31 |
| Keybuk | and what would be the opposite? | 01:31 |
| sadmac | Keybuk: when not? | 01:31 |
| 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:32 |
| 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:33 |
| 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:35 |
| 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:36 |
| sadmac | so can you pair them explicitly? | 01:37 |
| Keybuk | I think so | 01:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| Keybuk | means match the TTY variable from the tty-down event to the $TTY variable in the job | 01:44 |
| Keybuk | you'd use states for that, maybe | 01:45 |
| 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:46 |
| Keybuk | (ie. the daemon started will fail) | 01:47 |
| sadmac | true | 01:47 |
| Keybuk | obviously Upstart should never attempt to start it automatically | 01:48 |
| sadmac | cool | 01:49 |
| Keybuk | a more interesting question is if you start a job manually, should Upstart ever stop it automatically? :) | 01:49 |
| 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:50 |
| Keybuk | right | 01:51 |
| 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:53 |
| sadmac | Like make nih_info/error/whatever and the stdout of 'console output' services route to /dev/some/specific/tty | 01:54 |
| Keybuk | easiest way would be just to change upstart's own console | 01:55 |
| Keybuk | ie in init/main.c | 01:55 |
| 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:56 |
| 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:57 |
| Keybuk | certainly on Ubuntu, nothing other than /dev/console exists when init starts | 01:58 |
| 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 | 01:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| sadmac | I'll try that | 02:03 |
| sadmac | In fact I should set up a test job to do things with actual job output | 02:03 |
| * Keybuk yawns | 10:36 | |
| Keybuk | too damned windy again today | 10:37 |
| === 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 | ||
| Keybuk | dear valgrind, please exit 1 if you find an error, kthxbye | 20:37 |
| ion_ | Heh | 20:37 |
| Keybuk | hurrah | 20:45 |
| Keybuk | job->start_on is no more | 20:45 |
| Keybuk | start and the resulting environment are now atomic | 20:46 |
| 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:47 |
| ion_ | Neat. | 20:50 |
| Keybuk | do you think it matters why a job is stopped? | 20:54 |
| 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:55 |
| ion_ | A post-stop script might e.g. want to send email based on the job’s exit value, or something. | 20:56 |
| Keybuk | it should do that by hooking the stopped event ;) | 21:01 |
| ion_ | Good point. :-) | 21:01 |
| Keybuk | let me dump my thoughts here | 21:08 |
| Keybuk | start on foo or bar | 21:08 |
| Keybuk | stop on wibble or wibble | 21:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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 | 21:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!