[00:37] <myndzi> i'm trying to create an upstart script that lets me gracefully exit a program
[00:37] <myndzi> but in pre-stop a while loop that doesn't exit until the script is ready doesn't appear to be working
[00:38] <myndzi> http://pastie.org/private/3usocsfi2u74kijm85iqoa
[00:38] <myndzi> any idea what's wrong?
[00:40] <myndzi> it appears to work fine if i make a bash script and run it
[01:02] <xnox> myndzi: [[ is bashism. https://wiki.ubuntu.com/DashAsBinSh#A.5B.5B
[01:02] <xnox> myndzi: upstart uses /bins/sh, "dash" specifically on ubuntu.
[02:25] <myndzi> that explains it
[02:25] <myndzi> after a lot of messing around i got something that works and is clean :)
[02:25] <myndzi> thanks
[02:44] <quickdry21> I've been tackling the problem of running multiple processes from the same upstart script, any thoughts on this? https://gist.github.com/quickdry21/7312841
[03:09] <stgraber> quickdry21: you should look into upstart instances and use that instead of calling start-stop-daemon from a single job
[03:10] <stgraber> (so split into two jobs, one doing the for loop and spawning an instance of the other for each entry)
[03:16] <quickdry21> stgraber: would like to see an example of the upstart job that starts multiple single-upstart jobs... i've gotten the single-job to work but have had problems getting a loop to start other job with the script ending
[03:20] <stgraber> quickdry21: http://paste.ubuntu.com/6362512/
[03:26] <quickdry21> Nice - thanks, I'll be playing around with that. I knew start-stop-daemon was a bad way to to it.
[03:27] <stgraber> doing it with instances also lets you use the respawn keyword and per-instance pre-start/pre-stop/post-start/post-stop scripts just like with a standard job
[14:19] <Striki> I was wondering if there is a way to make sure one service does not stop until another service is stopped? As an example. We have task workers running in AWS and they are being auto scaled. So when AWS issues the shutdown command, celeryd (the task worker daemon), shuts down gracefully. I must make sure that mongos does not shut down before celeryd has been able to finish the tasks it's cleaning up.
[14:19] <Striki> I've looked at stop on stopped.. start on started.. etc. - but haven't found the right way
[14:36] <Striki> if I write in the task worker upstart "stop on stopping mongos" - would that ensure the task worker is stopped before mongos finishes shutting down?
[14:51] <xnox> Striki: yes.
[14:51] <xnox> Striki: there is a table of events & order they are emitted in.
[14:52] <xnox> Striki: stopping mongos is emitted once it was decided that "mongos" should stop. At that point everything this is "on stopping mongos" should succeed, before mongos is actually stopped.
[14:53] <xnox> Striki: but, i"m not sure how that will help you in the shutdown case, I thought there is a timeout after which everything gets killed, but you should have 5 seconds or so.
[14:53] <xnox> not sure that one can block shutdown.
[14:53] <xnox> jodh: can one block shutdown, whilst "stop on" haven't completed yet?
[14:56] <jodh> xnox: not reliably since Upstart doesn't handle the final shutdown atm. - /etc/init.d/sendsigs does.
[14:57] <jodh> Striki: see upstart-events(7) / http://upstart.ubuntu.com/cookbook/#ubuntu-well-known-events-ubuntu-specific for a list of events
[15:25] <Striki> xnox: ok thank you a lot!
[15:26] <Striki> and you as well jodh 
[20:28] <rcassidy> hi all! quick q: any way to reliably log who is using initctl to start/stop an upstart job?
[20:29] <rcassidy> (note: sadly, this is also a painfully old version of upstart.)
[21:06] <xnox> rcassidy: not sure how would that work. But if you increase logging you will see when jobs where started/stopped.
[21:06] <xnox> rcassidy: to do so, one needs to be root. So check/correlate with sudo logs.
[21:07] <xnox> "to do so" to stop/start jobs.
[21:07] <xnox> rcassidy: if you have custom policykit rules that you allow certain people start/stop certain jobs, check policy kit logs when those requests were granted and to who.
[21:08] <rcassidy> xnox: thanks for reply!
[21:08] <rcassidy> i think the best bet right now is to correlate with root logs, yes - thanks!