[00:01] xnox: and then yeah, doesn't work on boot [00:02] 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] styol: and log every line somewhere. [00:03] will do now [00:03] and bit by bit increase it. check the environment, upstart cleanses the environment, thus no typical variables are available. re-declare them. [00:03] styol: e.g. $HOME is _not_ set. [00:04] 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] initctl emit prepared FOO=bar [00:07] can pass variables. [00:09] 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] 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] 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] xnox: crapola, it must be the NAS mounting because that is the bare minimum.. trying without it now, probably will work [00:12] interesting! that would be nice [00:12] will try that indeed [00:13] 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] "env FOO=bar \n export FOO" in a.override (that is) [00:14] xnox: but without providing the argument it should take on bar? [00:14] check man 5 init, to see if .override file is support, env and export keys. [00:14] styol: correct. [00:14] delicieus, will check as soon as it done rebooting [00:14] also delicious [00:14] i no can englishes today [00:16] xnox: nutty, never reaches the emitted event http://pastie.org/9009721 [00:17] styol: try "initctl emit --no-wait prepared" [00:17] en route [00:17] --no-wait [00:17] Applies to the start, stop, restart and emit commands. [00:17] Normally initctl will wait for the command to finish before [00:17] returning. [00:18] For the emit command, finishing means that all of the jobs [00:18] affected by the event are running (or have finished for tasks) or [00:18] have been fully stopped. [00:18] thus e.g. if prepared event blocks then your job just gets stuck there. [00:19] 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] good night. [00:19] xnox: thank you so so so very much [00:19] it is very much appreciated [00:19] sleep well <3 [02:12] 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] Hey, one question [11:54] is the dbus service activation (https://lists.ubuntu.com/archives/ubuntu-devel/2010-December/032295.html) still working (also in a session)? [11:54] as I can't find a service that seems to use it [12:02] Trevinho: in recent ubuntu that has been disabled, there are plans to get that back, but it's not back in yet. [12:03] 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] 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] 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] xnox: well, the fact is that I want the service to start not on dbus, but on name activation [12:11] xnox: so say you can org.foo.bar then the service starts, handled by upstart, so that I can also stop it [12:11] Trevinho: that's not currently handled. [12:12] Trevinho: it used to be, and there are plans to introduce it. [12:12] Trevinho: do it manually =) [12:12] 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] Trevinho: you can do that. [12:14] xnox: ok [17:51] 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] 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] 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] 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] styol: post-stop is always executed when the job is stopped, irregardless as to /why/ the job is stopping. [23:28] totally makes sense [23:29] *since it calls the same wrapper script to stop that was used to start [23:29] styol: you may be need / want "post-start" and "post-stop" scripts. [23:30] 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] xnox: gotcha, post-start won't apply to the stop cycle which makes it work like desired, correct? [23:32] start is indeed script end script and therein lies the problem that post-start should solve.. awesome idea