[00:01] <styol> xnox: and then yeah, doesn't work on boot
[00:02] <xnox> styol: i meant make the job file (a.conf) minimal, start with just e.g. "script \n initctl emit prepared \n end script"
[00:02] <xnox> styol: and log every line somewhere.
[00:03] <styol> will do now
[00:03] <xnox> and bit by bit increase it. check the environment, upstart cleanses the environment, thus no typical variables are available. re-declare them.
[00:03] <xnox> styol: e.g. $HOME is _not_ set.
[00:04] <styol> xnox: that is one thing I came across with b.conf, decided to just provide the otherwise used environment variable as an argument
[00:07] <xnox> initctl emit prepared FOO=bar
[00:07] <xnox> can pass variables.
[00:09] <styol> xnox: ah right, but the wrapper script being ran by initctl was relying on an environment variable set like so `echo "export AQUA_CONFIG=$CONFIG" >> "/etc/profile.d/aqua.sh"`
[00:10] <styol> seems it is indeed not available, so i'll just have to dynamically create the upstart job with the config file specified as part of the command
[00:12] <xnox> styol: i think it's supported to have .override files. e.g. keep you main job as is, but e.g. have "env FOO=bar \n env FOO" in a.override
[00:12] <styol> xnox: crapola, it must be the NAS mounting because that is the bare minimum.. trying without it now, probably will work
[00:12] <styol> interesting! that would be nice
[00:12] <styol> will try that indeed
[00:13] <xnox> styol: this way you can do e.g. $ start a FOO=different, and FOO will be overriden with value "different" _and_ available inside all stanzas in a, _and_ due to export be part of events emitted from within it.
[00:13] <xnox>  "env FOO=bar \n export FOO" in a.override (that is)
[00:14] <styol> xnox: but without providing the argument it should take on bar?
[00:14] <xnox> check man 5 init, to see if .override file is support, env and export keys.
[00:14] <xnox> styol: correct.
[00:14] <styol> delicieus, will check as soon as it done rebooting
[00:14] <styol> also delicious
[00:14] <styol> i no can englishes today
[00:16] <styol> xnox: nutty, never reaches the emitted event http://pastie.org/9009721
[00:17] <xnox> styol: try "initctl emit --no-wait prepared"
[00:17] <styol> en route
[00:17] <xnox>        --no-wait
[00:17] <xnox>               Applies to the start, stop, restart and emit commands.
[00:17] <xnox>               Normally  initctl  will  wait  for  the  command  to finish before
[00:17] <xnox>               returning.
[00:18] <xnox>               For the emit  command,  finishing  means  that  all  of  the  jobs
[00:18] <xnox>               affected  by the event are running (or have finished for tasks) or
[00:18] <xnox>               have been fully stopped.
[00:18] <xnox> thus e.g. if prepared event blocks then your job just gets stuck there.
[00:19] <xnox> e.g. if there is a job "start on prepared and anotherevent" then you are blocked waiting for "anotherevent" which might never happen.
[00:19] <xnox> good night.
[00:19] <styol> xnox: thank you so so so very much
[00:19] <styol> it is very much appreciated
[00:19] <styol> sleep well <3
[02:12] <styol> xnox: so, I ended up moving the NAS mounting to /etc/fstab where it probably should be, and then within the upstart script I am using while and sleep to perpetually check for the existence of the expected file, which does seem to be working. Many thanks again.
[11:54] <Trevinho> Hey, one question
[11:54] <Trevinho> is the dbus service activation (https://lists.ubuntu.com/archives/ubuntu-devel/2010-December/032295.html) still working (also in a session)?
[11:54] <Trevinho> as I can't find a service that seems to use it
[12:02] <xnox> Trevinho: in recent ubuntu that has been disabled, there are plans to get that back, but it's not back in yet.
[12:03] <Trevinho> xnox: mh I se... so a workaround might be to use upstart init something as the exec for that dbus service or that won't work?
[12:05] <xnox> Trevinho: there are plenty of system jobs that start a daemon which happens to export itself on dbus. So yeah - start on started dbus \n exec foobard
[12:06] <xnox> Trevinho: recent upstarts have upstart-dbus-bridge such that events are generated when things appear/disappear from dbus and one can start/stop jobs according to those events. but that's reactive.
[12:10] <Trevinho> xnox: well, the fact is that I want the service to start not on dbus, but on name activation
[12:11] <Trevinho> xnox: so say you can org.foo.bar then the service starts, handled by upstart, so that I can also stop it
[12:11] <xnox> Trevinho: that's not currently handled.
[12:12] <xnox> Trevinho: it used to be, and there are plans to introduce it.
[12:12] <xnox> Trevinho: do it manually =)
[12:12] <Trevinho> xnox: yes, manually... and to do to do that, can I just add into the dbus .service file an exec= string such as initctl start my-service or that won't work?
[12:13] <xnox> Trevinho: you can do that.
[12:14] <Trevinho> xnox: ok
[17:51] <styol> Hmm.. any ideas why post-stop might be running on `start on runlevel [2345]? There is also `stop on runlevel [06]`, but from what I understand those run levels should be for halt and reboot 
[23:27] <xnox> styol: post-stop is run as part of the job life-cycle, e.g. after the main process has terminated (because it crashed, exited normally, or the job is being stopped)
[23:27] <xnox> styol: start on / stop on -> are simply the event trigger that cause changes to the job life-cycle: e.g. do whatever needs to happen to get the job from dormant to running; or from running to dormant again
[23:28] <styol> xnox: aha, that would explain it since it is somewhat of a wrapper script. Crapola. That being the case, a normal script definition doesn't work for stops which is what post-stop was supposed to solve since it calls the same wrapper script called to start
[23:28] <xnox> styol: post-stop is always executed when the job is stopped, irregardless as to /why/ the job is stopping.
[23:28] <styol> totally makes sense
[23:29] <styol> *since it calls the same wrapper script to stop that was used to start
[23:29] <xnox> styol: you may be need / want "post-start" and "post-stop" scripts.
[23:30] <xnox> styol: and read the cookbook to see which states the job go through (normal and task jobs) and which snippets of the job are executed when.
[23:31] <styol> xnox: gotcha, post-start won't apply to the stop cycle which makes it work like desired, correct?
[23:32] <styol> start is indeed script end script and therein lies the problem that post-start should solve.. awesome idea