/srv/irclogs.ubuntu.com/2012/06/15/#upstart.txt

djwnhere goes: how does one use a config file of env vars with upstart jobs?02:59
djwnlooks like sourcing the conf might work03:30
djszapisalhey11:03
djszapislangasek: ^ :)11:03
djszapishall I just use pre-start and post-stop if I would like to modprobe a module for my daemon, and rmmod that once that is stopped.11:04
djszapiso that the g_serial.ko module would only be needed for my module, and nothing else. Hence, I would not like to put into the /etc/modules file.11:04
jodhdjszapi: seems reasonable - some services already do this in Ubuntu.11:20
djszapishall I use exec before modprobe and rmmod, or not ?11:21
djszapijodh: does this look sane then ? http://paste.kde.org/500420/11:23
djszapisomething is broken with that, because after running my "start foobar" job, I am not getting the g_serial loaded, nor my binary running :(11:41
jodhdjszapi: I'd take out that sleep which is a hack seemingly. Also, I believe we have previously discussed the fact that Upstart runs all jobs with "/bin/sh -e", hence see: http://upstart.ubuntu.com/cookbook/#debugging-a-script-which-appears-to-be-behaving-oddly12:15
djszapijodh: hack, but needed anyway12:18
djszapijodh: unless you fix upstart.12:19
SpamapSdjszapi: isn't that sleep because the event you are trying to handle isn't handled properly in udev, not upstart?13:01
djszapino any real clue13:01
SpamapSdjszapi: I think I recall the issue was that you want this to be run if the device is plugged in, but not before some state has been reached in the boot13:02
djszapithe daemon should be running, once the device is recognized by the kernel, and then udev in userspace.13:02
SpamapSok, but the sleep 60 would imply that there is something else you need13:06
djszapi?13:06
djszapiit is a hackaround without knowing any better way.13:06
SpamapSand your start on doesn't mention the device attributes, just udevtrigger.. so its hard to agree that we need to 'fix upstart' when you're not using it the way it was designed13:07
SpamapSI'd expect a  something-device-added13:07
djszapiI use at this was designed13:08
djszapiagreed by few people13:08
djszapiyou can say all of us said bullshit13:08
djszapibut you need to technically prove that13:08
SpamapSIf you want a job to be run when a specific device is recognized by udev, 'start on udevtrigger' is not the way to do that.13:09
djszapiI would suggest reading the log back13:09
djszapithere was more than this discussed.13:09
SpamapS#start on tty-device-added DEVNAME=/dev/ttyUSB113:09
djszapiwe tried other triggerings as well13:09
SpamapSI suspect this failed for some odd reason?13:09
djszapinothing worked really :)13:09
djszapiwe tried to make both as a condition13:10
SpamapSI recall the case now13:10
djszapinot even that13:10
SpamapSbut not the real issue13:10
djszapiwe do not know the real issue13:10
djszapiit is either in udev, or in the linux kernel13:10
djszapithis is a workaround13:10
djszapiand it is gonna remain so until someone shows up a more elegant solution.13:10
SpamapSok, so while it is making upstart a pain to use, its not actually upstart doing something "wrong"13:11
SpamapSdjszapi: sorry to complicate things. Did you still have an unanswered question?13:13
djszapiif you can review the job, that would be great.13:13
djszapiand provide feedback.13:13
jodhdjszapi: I updated the Cookbook regarding the udev issue you've observed: http://upstart.ubuntu.com/cookbook/#careful-use-of-udev-events, but note that this is not an Upstart issue. Do you eventually get a udev event containing a ID_* variable?13:30
djszapijodh: no clue13:36

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