[09:14] <sveinse> Is there a way to stop a service from starting? E.g. during boot and within a job's script I want to stop another future job from starting. I can't control the other job's stanzas and it starts on runlevel
[09:14] <sveinse> Can I do that? This is on Ubuntu Natty, so its an older version of upstart
[20:16] <dkogan> anybody around to aid in defining an upstart .conf file?
[20:39] <SpamapS> dkogan: where are you stuck?
[21:16] <dkogan> SpamapS: Wrangling with basic of upstart's event-orientation instead of state-orientation
[21:17] <dkogan> I'd like my job to run when a particular USB device is plugged in AND when a network device is up
[21:17] <dkogan> either one is simple. but when I 'start on aaa and bbb', it doesn't work for post-boot USB insertions/removals
[21:18] <dkogan> so at boot it get the USB-inserted and network-up events, and runs the job
[21:18] <dkogan> then I pull the USB cable; upstart sees this and stops the job
[21:19] <dkogan> then I re-insert the cable. Upstart sees the usb-inserted event, but NO network-up event and doesn't start my job again
[21:19] <dkogan> this is really by design, since the network-up event is long-gone at that point. I essentially want a 'network-up' state and not a 'network-up' event. Is there a common idiom for this?
[21:20] <dkogan> Thanks
[21:29] <SpamapS> dkogan: right, basically you have a special case (at boot) and then hot-plug ..
[21:30] <SpamapS> dkogan: simplest thing to do is probably to just wait in pre-start until the network is available in the way you need it
[21:34] <dkogan> ok. I see
[21:34] <dkogan> thanks
[21:36] <SpamapS> dkogan: there are ways to make upstart coordinate it exactly.. but I think they'd complicate things more than simply testing that your desired network configuration is available
[21:38] <SpamapS> dkogan: another option is to work a bit like mountall.. just start up and wait for a signal, then send the signal to the daemon whenever new network interfaces come up.
[22:06] <dkogan> I'm ok with extra complexity if it makes things work "right". Let me look at mountall
[22:30] <SpamapS> dkogan: the basic method it uses is to always try to mount everything... and then re-try whenever it gets SIGUSR1
[22:30] <SpamapS> dkogan: so for NFS volumes, it just tries every time a network interface comes up.
[22:32] <dkogan> ok. but here "it" is mountall, NOT upstart, right?
[22:32] <dkogan> seems like this is something upstart should be able to do itself
[22:33] <dkogan> I think I'll change all my conditions to 'or' instead of 'and' and simply re-check them before running the daemon. so upstart will trigger multiple times, but my "exec" stanza will make sure that everything is up that needs to be
[22:34] <SpamapS> dkogan: right
[22:35] <dkogan> while you're here, another semi-related question
[22:35] <dkogan> I'm seeing that the usb-device-added event isn't triggered at bootup reliably
[22:35] <dkogan> works about 80% of the time, but not 100%
[22:36] <dkogan> I set the loglevel to debug and it's clearly not there when it doesn't work
[22:36] <SpamapS> dkogan: even right after a udevadm settle ?
[22:36] <dkogan> maybe....
[22:36] <dkogan> this would be in the log?
[22:36] <SpamapS> dkogan: well it happens early in boot right after udev is started
[22:38] <dkogan> looking at the log, usb-device-added appears when it works and does not appear when it doesn't; "udevadm" never appears in either case
[22:38] <dkogan> this with --verbose
[22:38] <SpamapS> dkogan: I don't know that anything eill be logged
[22:38] <dkogan> also, older upstart; 0.6.5 (from ubuntu lucid). Tried up to 0.9.something and it was still broken 20% of the time
[22:39] <SpamapS> dkogan: this is a udev issue, not an upstart issue
[22:39] <dkogan> ok. any debugging tips?
[22:40] <dkogan> even when upstart doesn't see the device at boot, udev does
[22:40] <dkogan> the device is there and works fine
[22:40] <SpamapS> dkogan: not really.. USB is outside my server-centric realm
[22:40] <dkogan> ok. thanks for listening :)
[22:40] <SpamapS> dkogan: so upstart's udev bridge starts *before* udev.. so if udev sees it and emits the event, then so shall upstart, in theory.
[22:41] <dkogan> udev definitely sees it. I have a udev rule set up to make symlinks to the device, and those are there always
[22:47] <dkogan> another interesting data point is that the boot takes about twice as long when it doesn't work...
[23:05] <SpamapS> dkogan: interesting indeed