[02:28] <j4m3s> helloooooo #upstart - n00b here
[02:30] <j4m3s> i have two erlang processes i want to create upstart scripts for, and they require a few other services to be running (haproxy and rabbitmq)
[02:32] <j4m3s> what's the better approach to this? creating events in rabbitmq that trigger the erlang processes to start   -or-   checking to see if the rabbitmq process is running?
[06:17] <SpamapS> j4m3s: better is to not assume those services are on the local box
[06:18] <SpamapS> j4m3s: start everything in parallel, make sure they poll/retry for services that they need.
[06:19] <SpamapS> j4m3s: that will make your services more robust and easier to scale out.
[14:53] <chris|> hi
[14:54] <chris|> I was wondering, is there a way to have the `kill timeout` stanza accept a variable that needs to be sourced from a defaults file?
[16:38] <SpamapS> chris|: no not really
[16:38] <SpamapS> chris|: you could put it into a .override file if you're worried about changing the packaged .conf tho
[16:45] <j4m3s> SpamapS, so polling for services would be more robust than waiting for an event?
[16:52] <chris|> SpamapS, not, that's not really the issue, thanks though
[17:03] <SpamapS> j4m3s: yes, because you can't wait for an event that happens on a different server
[17:04] <SpamapS> chris|: one of the ideas behind upstart is to be able to parse everything in one directory right at boot time. shelling out to source a default file is just more wasted boot time when you could put the value in the .conf file and have it parsed already
[17:04] <j4m3s> but you can poll for a process on another server? do you happen to know of a good example?
[17:04] <SpamapS> j4m3s: you'd be polling for its network service
[17:05] <SpamapS> j4m3s: apache can be started up before mysql, and still use mod_auth_mysql
[17:08] <chris|> SpamapS, sure, but whenever you are porting from debian or still might need SysinitV support for some reason, it's always desirable to not maintain multiple configurations
[17:10] <SpamapS> chris|: Indeed, if you *must* keep the /etc/init.d script alive on the same host, then the /etc/default/* file would be good
[17:11] <SpamapS> chris|: but that seems like a rare occasion... what service needs both the upstart job and the local init.d ?
[18:38] <kgraham> hello, using fedora/amazon linux and need to know how i would run a job before the network stops
[18:38] <kgraham> ie 'the first thing run on shutdown/reboot'
[18:39] <SpamapS> kgraham: start on deconfiguring-networking
[18:39] <SpamapS> kgraham: thats on Ubuntu 11.10 and later
[18:39] <SpamapS> kgraham: for fedora/amzn.. not sure.. maybe 'start on starting rc RUNLEVEL=[06]'
[18:40] <kgraham> ok thanks!
[18:40] <kgraham> i'll try that
[18:53] <j4m3s> SpamapS, so am i correct in saying, pid's are unnecessary with upstart?
[18:54] <SpamapS> j4m3s: pidfiles are usually not necessary, though there are still cases where they are needed when a program does weird stuff that makes it hard for upstart to track it
[18:57] <j4m3s> SpamapS, if i have a start on stopped job, if that job respawns does the other job also restart?
[18:59] <j4m3s> err lemme rephrase a lil more clearly, if i have a script for myapp, and it starts on stopped job foo, will myapp restart whenever foo respawns?
[19:02] <SpamapS> j4m3s: start on and stop on just change the "goal state" for a job. If its already 'start' , start on does nothing.
[19:04] <j4m3s> SpamapS, ok thanks
[22:38] <j4m3s> so i have a job that i've started with upstart and when i do initctl status foo it says foo is stopped/waiting
[22:38] <j4m3s> *stop/waiting
[22:39] <SpamapS> j4m3s: indeed, if the main process exits, and you don't have 'respawn' specified, thats the normal behavior
[22:39] <j4m3s> i have respawn specified
[22:39] <j4m3s> the process is running 
[22:39] <j4m3s> but upstart is having trouble tracking it i suppose
[22:39] <SpamapS> j4m3s: did it exit 0? if it exits with a 0 return code and no signal killing it, then that is also considered a normal exit, not somethign to respawn for
[22:40] <SpamapS> j4m3s: ah, so it daemonizes, but you haven't specified expect fork/daemon ?
[22:40] <j4m3s> correct
[22:40] <SpamapS> j4m3s: two options. 1: use expect fork/daemon, or tell the program not to daemonize
[22:40] <SpamapS> I prefer the latter
[22:42] <pulz> i have been testing upstart with some daemons latly, and in most cases upstart will report OK running, even if the process is killed 
[22:42] <pulz> any reason for this behavoiur ?
[22:45] <j4m3s> SpamapS, it appears rabbitmq-server created a bash wrapper that calls the erlang bins but doesn't exit
[22:45] <j4m3s> SpamapS, and the job i'm creating is for a erlang process
[23:00] <SpamapS> j4m3s: the only problem with the bash wrapper approach is that HUP, TERM, and KILL signals will be sent to the bash process. You want it to exec something that stays running/attached
[23:04] <j4m3s> SpamapS, so i circumvented the bash script and called erl from the upstart script, but it still daemonizes and exits cleanly
[23:04] <j4m3s> SpamapS, wait nvm my changes got wiped