[00:19] <alienth> hey folks, any solution for firing a script that forks 3 times?
[04:05] <SpamapS> alienth: sure.. don't do that. ;)
[04:06] <SpamapS> alienth: why does it need to fork (and exit) 3 times?
[06:01] <alienth> SpamapS: so, the situation is i'm trying to upstart memcached
[06:01] <alienth> memcached doesn't take a config file, so it uses a wrapper perl script, which forks, and then calls a daemon
[06:52] <SpamapS> alienth: heh, that weird perl script is a fail :)
[06:52] <SpamapS> alienth: there's really no need. Just run memcached directly
[06:52] <SpamapS> alienth: I actually wrote an upstart job for memcached a few months ago but never got around to getting it into Ubuntu
[13:42] <dcorbin_work> I have simple upstart script: https://gist.github.com/2405988  In circumstances we haven't figured out yet, jboss is shutting down gracefully, and then appears to restart 10-30 minutes later.  How can I verify that upstart is or is not involved in this?
[15:47] <SpamapS> dcorbin_work: start on starting enttek-inventory
[15:47] <SpamapS> dcorbin_work: I'd suspect that enttek-inventory is starting back up ;)
[15:57] <SpamapS> dcorbin_work: I wonder, why don't you 'stop on stopped enttek-inventory ?
[16:42] <dcorbin_work> SpamapS: I'm sure it could be better.  The real issue is figuring out why it's stopping in the first place.  Is there an upstart log that tracks the events?
[16:54] <SpamapS> dcorbin_work: you can do 'initctl log-priority info' and you'll get all the job status changes in syslog
[16:54] <JanC> also see http://upstart.ubuntu.com/cookbook/#debugging
[16:54] <SpamapS> dcorbin_work: also if it is stopping gracefully thats not really in upstart's realm. It will only respawn on a non-normal exit.
[17:01] <dcorbin_work> SpamapS: it is stopping gracefully.  But my expectation is that the stopping is no through upstart.  I'm just having to track it down.  Sadly, we've 40+ servers (and growing) and it's only happend 3 times in the last few months.
[17:04] <SpamapS> dcorbin_work: you can always change the notion of 'normal exit' to not include '0', so 'normal exit 99' would only not-respawn on exit code of 99. I think. You'd need the 'respawn' keyword too.
[17:06] <dcorbin_work> SpamapS: The problem we're facing is that it's getting shutdown in the middle of a "process" that won't restart automatically, even if jboss is respawn. i.e., respawning isn't enough to fix it for us.  We'll see what logging shows us.
[17:09] <SpamapS> ahh yeah thats probably not upstart's fault :) I bet you'll see 'exitted with 0 status'
[17:12] <dcorbin_work> SpamapS: I'm 99% sure it's not upstart, I just don't have any other good places to eliminate yet. :) 
[18:11] <mirth> does anyone know when autovacuuming runs and if it will lock the db if done during production hours?
[18:13] <SpamapS> mirth: either thats the wrong window, or somebody spliced your upstart man pages with your postgres man pages. :)
[18:16] <mirth> heh...i typed swapped username and channel name when joining :)
[18:16] <mirth> usually use 'upstart' as my nick