[15:41] xnox: so did you spend any more time on that qt theming issue? I'm poking at it now but don't want to duplicate debugging effort ;) [21:57] Why would initctl emit mounting MOUNTPOINT=/blah fail? [21:58] 2013-02-21 15:14:45-05:00 1116 ramdisk: + /sbin/initctl emit mounting MOUNTPOINT=/var/build/ramdisk 2013-02-21 15:14:45-05:00 1116 ramdisk: initctl: Event failed 2013-02-21 15:14:45-05:00 1116 ramdisk: EXITCODE=1 [21:58] Err [21:58] 2013-02-21 15:14:45-05:00 1116 ramdisk: + /sbin/initctl emit mounting MOUNTPOINT=/var/build/ramdisk [21:58] 2013-02-21 15:14:45-05:00 1116 ramdisk: initctl: Event failed [21:58] 2013-02-21 15:14:45-05:00 1116 ramdisk: EXITCODE=1 [21:59] Ubuntu Lucid here [21:59] Will looping till success work this around? [22:00] (I saw few mounting hooks with same MOUNTPOINT coming to my block-dependants task. I wonder if mountall already does the same work-around). [22:01] tartar: I am sorry, but what are you trying to do? [22:02] I am sticking centrify and couple more things early into the startup. [22:02] mountall emits these events for all mountpoints in /lib/init/fstab as well as anything in your fstab. [22:03] In particular, my ramdisk.conf simulates the mountall behavior by emitting a mounting hook [22:04] I need my ramdisk to block until centrify is ready and for this I added a block-dependants task [22:04] But I see that ramdisk's initctl emit fails to block returning the error above [22:05] have you seen: http://upstart.ubuntu.com/cookbook/#block-another-job-until-yours-has-started [22:05] emitting events will simply spawn more stuff to happen & get activated not less. [22:05] Yup, that's where I got the block-dependants thing [22:07] (BTW instance $JOB resulted in an error message saying that JOB did not exist. Perhaps my Lucid upstart is too old for the cook book) [22:07] I replaced that with instance mounting-$MOUNTPOINT [22:09] Should better read as mountall-$MOUNTING as I expect that mountall emits mounting hooks, and $JOB would receive "mountall" [22:10] err mountall-$MOUNTPOINT [22:10] ...if I understand this correctly [22:11] Actually now I see I went against the recipe by instantiating too many instances [22:12] should my block-dependants task use "instance mountall"? [22:48] I wish upstart clearly stated own mechanisms and those expected from other processes. [22:48] For now the cook book reflects its name giving mostly recipes rather than architectural knowledge. [22:50] To illustrate, the following phrase has unnecessary complications. The change of the mode from educational to instructional and back brings confusion. [22:50] "What you will find is that if you run the script above under /bin/sh, in all likelihood the file will never be created since regardless of whether you specify "-e" or not, the dash(1) shell (which /bin/sh is linked to on Ubuntu systems) has different semantics when it comes to sourcing compared with /bin/bash." [22:52] I would steer away from giving any instruction in a text about a thing that I would need to understand. [22:54] (I failed to understand the quoted phrase). [22:56] Enough vitriolic ranting.... [23:38] The section block-another-job-until-yours-has-started assumes that the blocker task multiplies itself to block each job emitting one of the hooks. Why? [23:38] Can a single blocker task block all hook emitters? [23:39] s/task/instance/