RedoubtIf I have an Upstart job start on event1 or (event2 and event3), I assumed it would run once upon event1, and again upon event2 and event300:31
RedoubtThat doesn't seem to be the case00:31
RedoubtCan anyone explain why?00:31
RedoubtIt only seems to run once00:32
RedoubtBut if I have a job start on event1, and another job start on (event2 and event3), both jobs run00:32
stgraberRedoubt: well, a job only starts once, unless you define it as a task or use upstart's instances00:37
RedoubtOh my apologies-- it is a task00:37
stgraberhmm, odd, my understanding of tasks was that they'd re-trigger every time one of the conditions would match... /me tests00:38
RedoubtThat's what I thought too. I can give you my specific task if you like00:39
stgraberthat simple example seems to show that upstart behaves as you'd expect...00:41
RedoubtWell this is fortunate. I'm working on that bluetooth upstart job (bug 1073669) which you're involved in00:44
stgrabercan you pastebin what you've got currently?00:46
RedoubtWell, here are my test scripts: http://paste.ubuntu.com/1393294/00:53
RedoubtBecause when I test them like you did (via initctl), they do seem to work as expected00:54
RedoubtBut when I reboot, I only get one print from kyle-all.conf, and the event that triggers it is only local-filesystems00:54
RedoubtAll the others print as well, but kyle-all.conf only prints once instead of the three times I expected00:55
stgraberhmm, so the problem seems to be that it's expecting the local-filesystems to be re-emited too which it won't00:58
stgrabertesting some alternatives here00:58
RedoubtOh interesting, so I have a fundamental misunderstanding, I guess. I sort of thought of events as... states, I guess00:59
RedoubtSomething that was persistent00:59
RedoubtThat doesn't actually make sense though, so... :)00:59
stgraberupstart basically tracks event state per job to know when the start condition matches, but as soon as it matches it looses that state, or so it looks like anyway :)01:00
RedoubtThat makes perfect sense01:01
RedoubtBut interferes with all my plans, darnit01:01
RedoubtHmm... it would be nice if it analyzed start conditions a little more and was smarter with that01:02
RedoubtThe only way around this that I can think of is three separate scripts. Yuck01:03
RedoubtI would probably do four and make one an instance01:04
stgraberwell, you could keep rfkill-restore as it's and add a new rfkill-restore-interface which would roughly be01:06
stgraberstart on net-device-added or bluetooth-device-added01:06
stgraberexec initctl start --no-wait rfkill-restore01:06
stgraberthe INTERFACE environment variable should then be sent all the way to the rfkill-restore job that can then change behaviour slightly when it's defined01:08
RedoubtWell, what about local-filesystems?01:09
stgraberthat'd still be the start condition of the rfkill-restore.conf job, just not of the -interface one01:10
RedoubtWould exec initctl start --no-wait rfkill-restore fail if local-filesystems hadn't happened?01:11
stgraberhmm, no, it'd run the code anyway but would exit 0 immediately because of the first if statement in rfkill-restore.conf01:12
RedoubtIf not, this two-script combo is the same as just changing rfkill-restore starts to local-filesystems or net-device-added or bluetooth-device-added, right?01:13
stgraberso that wouldn't be a problem as such a case would mean that the main rfkill-restore call didn't happen yet and that the interface will be rfkilled a bit later01:13
stgraberhmm, good point, and I guess doing that change + adding the needed tweaks to the shell script would do the trick01:13
stgraberno need for a separate job01:14
RedoubtOkay, I like that. I really appreciate your help man, I've made a couple forum posts about this and no one seems to have any clue01:14
RedoubtThat saving states until start condition met thing... I'm not sure the docs explicitly mention that. Not sure I ever would have learned it :)01:15
stgraberhehe, np and thanks for the work on that bug. I've been quite busy with other things lately, one of which being upstart development, so it's good to have you help with this one :)01:15
RedoubtOh my pleasure!01:16
stgraberyeah, the state saving is a bit odd, it makes sense when you think of it, but it can surprise you :) I believe Scott (original upstart author) covered that in some blogpost a few years ago, or maybe it was a session at UDS, can't recall... anyway, may be something we should better cover in the cookbook.01:17
SpamapSRedoubt: if you want to poke something when network connections change, just use /etc/network/if-up.d01:19
SpamapSRedoubt: upstart is a bit low level for what you're intending01:20
SpamapSRedoubt: also if you do need to do state tracking, you can use the 'wait-for-state' job added in Ubuntu 11.0401:21
Redoubtstgraber: Yeah, if you think of it, it would be handy to mention that in there somewhere.01:21
RedoubtSpamapS: Huh, wait-for-state is a new one for me, thank you for the reference!01:22
stgraberSpamapS: wait-for-state only works for jobs though, not for events right? (it waits for a job to get into the WAIT_FOR state)01:23
SpamapSstgraber: indeed.. the idea though, is that you use the job to track state.. and then you just call wait-for-state with that job when you want to block on a state01:24
stgraberSpamapS: Redoubt is helping me with a limitation of my rfkill-restore job I introduced in 12.10 where some devices you can rfkill show up after the rfkill-restore job is done. The only way to reliably cover this case is to trigger the restore job when network or bluetooth devices show up.01:24
stgraberSpamapS: initially I thought I added the local-filesystems requirement of rfkill-restore because I actually needed local-filesystems, but I don't really as the job itself is checking for the paths it needs and exiting if they're not there.01:25
stgraberSpamapS: so the simple fix for our problem is to change from "start on local-filesystems" to "start on local-filesystems or net-device-added or bluetooth-device-added" which will guarantee the job to be triggered once per boot + once per device01:26
stgraberSpamapS: with some of the per-device call potentially being no-ops if the filesystem isn't there yet, but in such case, the rfkill-restore job will be called a bit later anyway and will take care of any leftovers01:26
SpamapSstgraber: Right, so it sounds like you just need a single task, with start on net-device-added or bluetooth-device-added , and an instance value that will be unique enough to run them at the right time01:26
SpamapSstgraber: that won't actually guarantee that it will be run once per device01:26
stgraberSpamapS: as it's a task, we don't even need to use instances01:27
SpamapSstgraber: thats not true at all01:27
SpamapSstgraber: the only thing task does is guarantee that it will block until it reaches stopped again01:28
SpamapSstgraber: it does not serialize events. If the state is already 'start/running' .. the next event in the or is ignored01:28
RedoubtSpamapS: So you think instances are a better way to go?01:28
stgraberSpamapS: it won't be start/running because the task exits in a few miliseconds01:29
SpamapSI think instances is the only way to go if you need to run it once per event01:29
SpamapSstgraber: >< cross your fingers? ;)01:29
SpamapSthats actually again where wait-for-state works, because you can wait for stopped on a task, but start it. That way all of the waiters will block until it has been run once01:31
stgraberSpamapS: well, the way the script is designed, we don't need the value of INTERFACE, whenever it triggers, it'll restore the rfkill value of any interface it hasn't restored yet. So if we have multiple devices showing up at the same time and we end up only triggering the job once, that's fine as it'll cover all of them anyway01:31
SpamapSstart wait-for-state WAITER=$UPSTART_JOB WAIT_STATE=stopped GOAL_STATE=start WAIT_FOR=rfkill-restore01:32
SpamapSassuming rfkill-restore is a task01:32
SpamapSstgraber: sounds like a very tight race..01:33
SpamapS[dev1-added][rfkill-restore starts and handles dev1][dev2-added][upstart acks that rfkill-restore is done and returns to stop/waiting]01:34
SpamapSseems like there's a very tiny window for dev2 to not be handled01:34
RedoubtAn instance would then require a helper script, correct?01:36
Redoubthelper job, rather01:36
RedoubtTwo jobs: One instance, one job to run the instance01:36
SpamapSWell, the helper is wait-for-state01:36
RedoubtSo in order to use wait-for-state the job must be an instance?01:37
SpamapSbut yes, there will be two jobs, one which lists the events, and runs the wait-for-state command for each instance of itself, and then the actual rfkill-restore01:37
SpamapSRedoubt: no, its just in this case, it makes more sense that way as it closes the race, even if the race is tiny01:37
RedoubtOf you have a job that lists the events and runs wait-for-state, doesn't that provide a window for the race to occur as well?01:38
stgraberSpamapS: I'd actually have to check, but I vaguely remember the udev events being blocking on the udev side, which is that until the initctl done by udev returns, no other uevent can be emitted01:39
stgraberhmm, upstart-events marks them as signal, so I guess not01:40
stgraberah no, I'm being confused with some other weird udev rules we have somewhere else that doesn't use the bridge01:40
SpamapSstgraber: so udev will queue up the events until the waited for event is handled?01:41
SpamapSbecause that means you can just handle with or's01:41
stgraberSpamapS: nope, as I said, I got confused with some other hacks I had to look at recently where something indirectly does an "initctl emit" from a udev hook, which in this case indeed blocks everything on udev's side. But that's not the case for those event emitted by upstart-udev-bridge.01:43
stgraberSpamapS: so your solution is fine, as much as I dislike introducing an extra job to cover that.01:45
SpamapSstgraber: its a bug in upstart not to have this built in01:48
SpamapSstgraber: In fact we talked about just changing or's to work this way, but we'd have to call that upstart 2.0 or something.. because it would likely break some things01:49
RedoubtSpamapS: That would be handy!01:49
SpamapSYeah, it would01:50
stgraberyeah, or just add another keyword "or2" or whatever, not sure what'd be the most confusing for the users :)01:50
SpamapSwell, its actually not or that is broken, per se01:50
SpamapSits blocking in general01:50
SpamapSit just doesn't get done if the goal does not change01:50
SpamapSwhat should happen is, on a blocking event emission, we should look for any start on's or stop ons that match, and then flip only the ones that need changing, but block if there are other events already being waited on for any that don't change01:52
SpamapSOf course, another one would be to finally do the "state rewrite" that keybuk intended, which would introduce a 'while' keyword and allow you to do 'while bluetooth-device is running'01:53
=== jMCg_ is now known as jMCg
stgraberyay, my prctl branch builds and appears to work!15:19
stgraberstgraber 25187  0.0  0.0  41988  1928 pts/4    S+   10:22   0:00  |   \_ /home/stgraber/data/code/upstart/init --session --confdir=~/.init/15:24
stgraberstgraber 25201  0.0  0.0   4328   360 ?        S    10:24   0:00  |       \_ /bin/sleep 200015:24
stgraberand as init is now the parent, I can even stop that job (in the past it'd just hang as it wouldn't receive the SIGCHILD)15:25
SpamapSstgraber: *nice*17:02

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