[10:27] hi! i am doing something like this "start on (postinsts-done or database-up DB=mydb)" is it possible to know which signal (postinsts-done or database-up) triggered the start ? [10:43] afournier: well DB environment variable will be set in the later case. [10:46] afournier: and in the former case UPSTART_EVENTS [10:46] afournier: see http://upstart.ubuntu.com/cookbook/#standard-environment-variables [10:46] ok [10:47] afournier: just check upstart_events and see what it has in it. [10:47] (all caps) [10:47] yes [10:47] thanks xnox [10:51] i love upstart [10:52] =) === doko_ is now known as doko [16:26] i don't understand the shutdown / reboot process [16:27] i have a a bug in a job so a chain of process does not stop [16:27] but then why upstart does not end up killing everything [16:53] on ubuntu upstart does kill all processes it tracked [16:54] if the pid of the job does not match the pid of processes it tracks upstart will not kill it [16:54] later /etc/init.d/sendsigs kills everything [17:10] so it means upstart does cannot track some of my jobs [17:11] could be because of a wrong expect stanza... === JanC_ is now known as JanC [18:57] yes [20:13] We've got an upstart job where occasionally the process doesn't respond to SIGTERM and continues to run. This for some reason allows multiple processes to start when starting the job again (like the upstart job lost track of the previous process). Is there something we can do with the upstart job (or something to troubleshoot) to see why it's allowing this? For reference, here is the upstart job https://github.com/MythTV/packaging/blob/master/de [20:13] b/debian/mythtv-backend.upstart [20:13] https://github.com/MythTV/packaging/blob/master/deb/debian/mythtv-backend.upstart [20:25] hmm, reading thought the expect parts of the cookbook. This is probably what I need. Is there a way to see what PID(s) upstart is currently tracking for a job? [20:51] tgm4883: the mythtvbackend should be prepended with exec [20:51] e.g. see /etc/init/hwclock.conf [20:52] xnox, and that will make it so upstart stops losing track of it? [20:53] tgm4883: next please start it and check that the pid from $ status mythtv-backend matches pgrep mythbackend [20:53] when only one mythbackend is running [20:54] if they don't match then expect/fork stanza is not right [20:54] if the pid is what you expect then [20:54] we shall wait for jodh to wake up tomorrow to poke at it a little more [20:55] xnox, what does the exec do? [20:56] looking at the status PID (without using exec), it's not right [20:56] http://upstart.ubuntu.com/cookbook/#exec [20:57] tgm4883: yeah, you are probably tracking the pid of "test -f" call ;-0 [20:57] root 1738 0.0 0.0 4400 612 ? Ss Feb08 0:00 /bin/sh -e /proc/self/fd/9 [20:57] that is what it's tracking [20:57] actual PID is 1740 [20:57] I'm assuming because the upstart job calls a wrapper script [20:57] and that expect isn't right [20:58] tgm4883: kill everything, add expect, start up compare the pids [20:58] xnox, can I just edit /etc/init/mythtv-backend.conf directly and restart? [20:59] xnox, or do I need to notify upstart that some changes happened [20:59] tgm4883: no just edit and it will pick it up (it uses inotify) [20:59] if you are on overlayfs then you could use: initctl reload-configuration [20:59] to be sure. [20:59] tgm4883: if the pids are still 2 digits apart you need expect daemon [21:00] if one, than it's a fork [21:00] expect fork [21:01] with exec, looks like it's tracking the right PID [21:01] with using expect at all [21:01] if the pids are correct [21:01] than it all should just work ;-) [21:01] :) [21:01] xnox, have time for one more question? [21:01] and sigterm is now send to the correct process =) [21:02] tgm4883: go on. [21:02] xnox, does upstart allow for conditional "start-on" yet? eg. we'd like to do "start on mysql started" but only if mysql is installed [21:03] I know it was on the roadmap at one point, but I haven't heard anything about it [21:05] start on mysql or (other) [21:05] in pre-start: [21:06] check for status mysql and if job is unknown continue, if known and not started yet abort starting just yet. [21:08] ok, so we can do that in the pre-start script? [21:08] sorry, trying to find this in the cookbook [21:10] start on mysql or (other-events) [21:10] pre-start script [21:10] ! status mysql || { stop; exit 0; } [21:10] end script [21:10] start on started mysql or (other-events) that is [21:15] ok, and that will still work even if mysql isn't installed? [21:15] I misunderstood the cookbook then [21:15] (or it changed since we first made the upstart job) [22:44] tgm4883: start on started mysql will not give any errors [22:44] tgm4883: if nothing ever emits 'started mysql' ... [22:44] tgm4883: then the job never starts [22:51] SpamapS, well that's not really what we want [22:52] SpamapS, we'd like to start on mysql started, but account for instances where mysql isn't installed (eg. it's installed on another machine) [22:59] tgm4883: hang on... [23:06] tgm4883: how is upstart supposed to know about other hosts? [23:06] SpamapS, it's not. It's just suppose to assume that "If mysql is install, wait for mysql to start. Otherwise continue starting on other deps" [23:07] tgm4883: if you can handle that case in your app, just start whenever [23:07] no guarantees the other host will be up ever [23:07] SpamapS, it's not my app. we just package it [23:08] SpamapS, I'm just trying to make this the easiest on users without causing loads of work for them to do [23:11] tgm4883: perhaps your pre-start should spin polling for the mysql server [23:12] SpamapS, currently it does. We look for /usr/sbin/mysqld [23:12] SpamapS, but that is a really crappy way to do it [23:12] no no no [23:12] the port [23:12] wherever it is [23:13] while ! mysqladmin ping ...