| styol | xnox: and then yeah, doesn't work on boot | 00:01 |
|---|---|---|
| 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:02 |
| 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:03 |
| 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:04 |
| xnox | initctl emit prepared FOO=bar | 00:07 |
| xnox | can pass variables. | 00:07 |
| 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:09 |
| 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:10 |
| 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:12 |
| 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:13 |
| 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:14 |
| styol | xnox: nutty, never reaches the emitted event http://pastie.org/9009721 | 00:16 |
| 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:17 |
| 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:18 |
| 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 | 00:19 |
| 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. | 02:12 |
| 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 | 11:54 |
| xnox | Trevinho: in recent ubuntu that has been disabled, there are plans to get that back, but it's not back in yet. | 12:02 |
| 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:03 |
| 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:05 |
| 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:06 |
| Trevinho | xnox: well, the fact is that I want the service to start not on dbus, but on name activation | 12:10 |
| 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:11 |
| 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:12 |
| xnox | Trevinho: you can do that. | 12:13 |
| Trevinho | xnox: ok | 12:14 |
| 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 | 17:51 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| styol | xnox: gotcha, post-start won't apply to the stop cycle which makes it work like desired, correct? | 23:31 |
| styol | start is indeed script end script and therein lies the problem that post-start should solve.. awesome idea | 23:32 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!