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 | 09:14 |
dkogan | anybody around to aid in defining an upstart .conf file? | 20:16 |
SpamapS | dkogan: where are you stuck? | 20:39 |
dkogan | SpamapS: Wrangling with basic of upstart's event-orientation instead of state-orientation | 21:16 |
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:17 |
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:18 |
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:19 |
dkogan | Thanks | 21:20 |
SpamapS | dkogan: right, basically you have a special case (at boot) and then hot-plug .. | 21:29 |
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:30 |
dkogan | ok. I see | 21:34 |
dkogan | thanks | 21:34 |
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:36 |
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. | 21:38 |
dkogan | I'm ok with extra complexity if it makes things work "right". Let me look at mountall | 22:06 |
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:30 |
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:32 |
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:33 |
SpamapS | dkogan: right | 22:34 |
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:35 |
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:36 |
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:38 |
SpamapS | dkogan: this is a udev issue, not an upstart issue | 22:39 |
dkogan | ok. any debugging tips? | 22:39 |
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:40 |
dkogan | udev definitely sees it. I have a udev rule set up to make symlinks to the device, and those are there always | 22:41 |
dkogan | another interesting data point is that the boot takes about twice as long when it doesn't work... | 22:47 |
SpamapS | dkogan: interesting indeed | 23:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!