/srv/irclogs.ubuntu.com/2008/12/12/#upstart.txt

fbond"start on started rc2" doesn't really do what I want.15:26
fbondI think what I want to do would require the rc2 job to emit an event like "rc2-finished".  This is different from "stopped rc2" because that happens regardless of whether or not rc2 was killed due to switching runlevels or rc2 finished normally (and we're in runlevel 2).15:49
fbondAm I thinking about this wrong?15:49
fbondCan I do conditional "start on " directives?15:50
fbondLike "start on runlevel 2 and stopped rc2"?15:50
fbondThat doesn't seem like it would work because it's not an event that happens at a specific time...15:50
sadmac2fbond: I believe the stopped event has an environment variable (I think its RESULT) that says whether it was a success or a failure15:53
sadmac2fbond: so start on stopped rc2 RESULT=ok15:53
fbondsadmac2: My only concern is a race condition.15:54
sadmac2fbond: what race condition?15:55
fbondIf we go into runlevel 2 and then switch to runlevel 3 before rc2 has totally finished, is it not at all possible that some odd timing (rc2 finishes just after we enter runlevel 3) will lead to me receiving the events out of order?15:55
fbondLet me be more explicit:15:56
fbondI want a job with:15:56
fbondstart on stopped rc2 RESULT=ok15:56
fbondstop on runlevel [!2]15:56
fbondThis will make sure the job doesn't get started until after the rc2 init scripts have finished.15:56
sadmac2those two lines should do it15:57
fbondBut what if rc2 init scripts finish normally just after runlevel 3 is entered but before upstart kills rc2?15:57
fbondIs that not possible?15:57
fbondIf that happened, my job would be running in runlevel 3.15:58
fbond(Sorry if I'm making this overly complicated.  I'm just wondering what does upstart do to prevent this?)15:58
sadmac2I don't know that that can happen15:59
fbondI think it can...16:00
sadmac2but I'm not certain now...16:00
fbondBecause runlevel 3 is an event, so it happens before upstart kills rc2.16:00
fbondThat leaves a brief window for things to go wrong (unless I'm missing something).16:00
sadmac2fbond: upstart is single-threaded internally, so I think that the normal exit of rc2 and the runlevel event would be serialized16:02
sadmac2fbond: if the runlevel event happened first, upstart would register rc2 as "killed" even though it had terminated successfully16:02
sadmac2I think16:02
fbondsadmac2: The runlevel event *must* happen first, right?16:02
fbondBecause rc2 has "stop on runlevel [!2]"16:02
fbondsadmac2: Okay, is upstart smart enough to say "rc2 failed because I would have killed it"?16:03
fbondTime to look at the source I guess...16:03
sadmac2fbond: its more dumb enough I think :)16:03
fbondsadmac2: ;)16:04
fbondAny idea where in the source I ought to look?16:05
fbondThis is hard to grep for :)16:05
sadmac2fbond: init/job.c will be helpful16:06
fbondsadmac2: thanks16:06
fbondsadmac2: Doesn't look good.16:08
fbondjob_child_reaper appears to set the job status as failed based on process exit status.16:09
fbondThat doesn't take into account what upstart may have wanted to do to the process. ;)16:09
sadmac2fbond: but that's fine16:10
fbondIt is?16:10
sadmac2fbond: because the runlevel event hasn't been processed at all yet16:10
sadmac2fbond: so runlevel 3 hasn't been received by anything16:10
fbondI don't see how.16:10
sadmac2fbond: upstart can only be doing one thing at a time16:10
fbondYou are saying the event has been emitted but not finished processing?16:11
sadmac2fbond: not even started processing.16:11
fbondThat can't be true.16:11
fbondBecause stopping rc2 happens in response to the runlevel 3 event.16:11
fbondRight?16:11
sadmac2fbond: that's a different case though :)16:11
fbondI'm not sure I follow you.  I've been talking about the same case the whole time. ;)16:11
fbondsadmac2: Do we agree that there is a race in that particular case?16:13
sadmac2fbond: for your race condition, either the child is reaped before the runlevel event is processed (in which case it appears rc2 finished before runlevel was ever emitted) OR the runlevel event is processed before the child is reaped (in which case upstart tries to kill it anyway and just registers a failure)16:13
fbondsadmac2: There is a third case.16:14
fbondThe process dies just before upstart tries to kill it.16:14
fbondThe failure isn't registered because the process exited normally.16:14
sadmac2fbond: upstart should call it a failure if it explicitly killed something16:15
sadmac2fbond: and I think it won't even wait for the reap result.16:15
fbondsadmac2: That's not what the code I'm looking at says (unless I'm missing something).16:16
sadmac2fbond: I have to be somewhere. I'll be back a bit later16:16
fbondIf you reviewed the code and told me I was wrong I would be exceedingly pleased.16:16
fbondsadmac2: Okay, no worries.16:16
sadmac2fbond: ah, looks like I have more time than I thought16:24
fbondsadmac2: Good for you. ;)16:25
fbondsadmac2: BTW, I'm looking at upstart source from Hardy (0.3.9-2).16:26
sadmac2fbond: ohh16:26
sadmac2fbond: I was looking at 0.5.016:26
sadmac2hold on...16:26
sadmac2fbond: ok, the RESULT variable is new in 0.5.016:44
sadmac2so that won't work :)16:44
fbondsadmac2: Ah.  So I should just write an init script, I guess.16:45
sadmac2fbond: that's an option16:45
sadmac2probably the best option16:45
fbondsadmac2: Okay, KISS, I guess.16:46
sadmac2heh16:46
fbondsadmac2: Too bad, though.16:46
fbondI just want upstart to take over already.16:46
fbondCan't use it to replace an init script until all of the init scripts are gone.16:46
fbondThat's a bummer.16:46
fbondsadmac2: I think that still leaves an obvious use case for upstart that is not well supported ... ?16:48
fbondsadmac2: But I won't be needing it for my current project.16:48
fbondsadmac2: Thanks for your help!16:48
sadmac2fbond: np16:49
keesjfbond: itsn't that a contraditon ?23:19
keesjfbond: I was reading the backlog. I see you found something23:21

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!