[02:59] <djwn> here goes: how does one use a config file of env vars with upstart jobs?
[03:30] <djwn> looks like sourcing the conf might work
[11:03] <djszapi> salhey
[11:03] <djszapi> slangasek: ^ :)
[11:04] <djszapi> shall 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] <djszapi> so 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:20] <jodh> djszapi: seems reasonable - some services already do this in Ubuntu.
[11:21] <djszapi> shall I use exec before modprobe and rmmod, or not ?
[11:23] <djszapi> jodh: does this look sane then ? http://paste.kde.org/500420/
[11:41] <djszapi> something is broken with that, because after running my "start foobar" job, I am not getting the g_serial loaded, nor my binary running :(
[12:15] <jodh> djszapi: 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-oddly
[12:18] <djszapi> jodh: hack, but needed anyway
[12:19] <djszapi> jodh: unless you fix upstart.
[13:01] <SpamapS> djszapi: isn't that sleep because the event you are trying to handle isn't handled properly in udev, not upstart?
[13:01] <djszapi> no any real clue
[13:02] <SpamapS> djszapi: 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 boot
[13:02] <djszapi> the daemon should be running, once the device is recognized by the kernel, and then udev in userspace.
[13:06] <SpamapS> ok, but the sleep 60 would imply that there is something else you need
[13:06] <djszapi> ?
[13:06] <djszapi> it is a hackaround without knowing any better way.
[13:07] <SpamapS> and 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 designed
[13:07] <SpamapS> I'd expect a  something-device-added
[13:08] <djszapi> I use at this was designed
[13:08] <djszapi> agreed by few people
[13:08] <djszapi> you can say all of us said bullshit
[13:08] <djszapi> but you need to technically prove that
[13:09] <SpamapS> If 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] <djszapi> I would suggest reading the log back
[13:09] <djszapi> there was more than this discussed.
[13:09] <SpamapS> #start on tty-device-added DEVNAME=/dev/ttyUSB1
[13:09] <djszapi> we tried other triggerings as well
[13:09] <SpamapS> I suspect this failed for some odd reason?
[13:09] <djszapi> nothing worked really :)
[13:10] <djszapi> we tried to make both as a condition
[13:10] <SpamapS> I recall the case now
[13:10] <djszapi> not even that
[13:10] <SpamapS> but not the real issue
[13:10] <djszapi> we do not know the real issue
[13:10] <djszapi> it is either in udev, or in the linux kernel
[13:10] <djszapi> this is a workaround
[13:10] <djszapi> and it is gonna remain so until someone shows up a more elegant solution.
[13:11] <SpamapS> ok, so while it is making upstart a pain to use, its not actually upstart doing something "wrong"
[13:13] <SpamapS> djszapi: sorry to complicate things. Did you still have an unanswered question?
[13:13] <djszapi> if you can review the job, that would be great.
[13:13] <djszapi> and provide feedback.
[13:30] <jodh> djszapi: 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:36] <djszapi> jodh: no clue