[00:27] <statim> hey guys, this is probably a dumb question but i cant wrap my head around how this works: http://pastie.org/private/z8biw4h8ddsoth4oe7iw i can see how it will "start" mongod, but what i dont understand is how it knows what to do to stop it
[00:28] <broder> statim: "stop on runlevel [06]"?
[00:29] <statim> broder:  right, but what does it execute to stop it?
[00:29] <statim> i only see a script for starting it
[00:29] <broder> statim: it keeps track of the process that gets started and kills it
[00:30] <broder> (well, sigterms it)
[00:30] <statim> oh i see.  so unlike init.d scripts it just needs to know how to start it, then the rest is process managed by upstart
[00:31] <broder> yes. that's why the "expect" stanzas are so important when you create a new job
[00:32] <statim> broder, and is restart provided automatically by this as well? or what if there was a specific signal the program new to use to restart itself like USR1?
[00:32] <statim> knew*
[00:32] <broder> "reload" is SIGHUP
[00:32] <broder> "restart" is equivalent to "stop; start" iirc
[00:33] <statim> ok cool
[00:51] <ion> restart isn’t equivalent to stop; start.
[00:51] <ion> See restart(8)
[00:57] <broder> ah right. it's like "stop; don't-read-the-new-config; start" :)
[06:20] <statim> does 'instance' really work? ive got instance JOB_1 in script1, instance JOB_2 in script2, but launch the same executable with different ports.  but it seems they still conflict even with the different instance names given to them
[06:55] <statim> ah nm, it looks like it was actually start-stop-daemon that was not allowing the second instance, not upstart.  gave unique pidfile options to each start-stop-daemon and now it works
[06:56] <broder> statim: instances are for starting a single job multiple times. upstart never needs instances for two distinct jobs
[14:53] <JanC> right, and the instance names could be used to create a unique pidfile
[14:59] <JanC> using "instance $PORT" or something like that
[15:01] <JanC> and using $PORT to provide the necessary options to the program and to start-stop-daemon
[23:38] <statim> hey guys i have a job that remains at stop/killed, process 4930. that pid isnt running any more, and i cleaned out everything i can think of to get it back to a clean state, but it still keeps that status.  is there a way to 'reset' it?
[23:57] <ion> It’s easy to get the current version of Upstart confused by lying to it about the forking behavior of the main process with “expect”. If you don’t want to reboot, run workaround-upstart-snafu 4930. http://heh.fi/tmp/workaround-upstart-snafu
[23:58] <ion> A future version will be more robust in that regard.