/srv/irclogs.ubuntu.com/2011/11/27/#upstart.txt

statimhey 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 it00:27
broderstatim: "stop on runlevel [06]"?00:28
statimbroder:  right, but what does it execute to stop it?00:29
statimi only see a script for starting it00:29
broderstatim: it keeps track of the process that gets started and kills it00:29
broder(well, sigterms it)00:30
statimoh i see.  so unlike init.d scripts it just needs to know how to start it, then the rest is process managed by upstart00:30
broderyes. that's why the "expect" stanzas are so important when you create a new job00:31
statimbroder, 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
statimknew*00:32
broder"reload" is SIGHUP00:32
broder"restart" is equivalent to "stop; start" iirc00:32
statimok cool00:33
ionrestart isn’t equivalent to stop; start.00:51
ionSee restart(8)00:51
broderah right. it's like "stop; don't-read-the-new-config; start" :)00:57
statimdoes '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 them06:20
statimah 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 works06:55
broderstatim: instances are for starting a single job multiple times. upstart never needs instances for two distinct jobs06:56
JanCright, and the instance names could be used to create a unique pidfile14:53
JanCusing "instance $PORT" or something like that14:59
JanCand using $PORT to provide the necessary options to the program and to start-stop-daemon15:01
statimhey 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:38
ionIt’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-snafu23:57
ionA future version will be more robust in that regard.23:58

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!