[15:54] <fission6> i just wrote my first upstart script for uwsgi, how cna i test it?
[16:01] <SpamapS> fission6: put it in /etc/init/uwsgi.conf and run 'sudo start uwsgi'
[16:02] <SpamapS> fission6: you can also do 'init-checkconf uwsgi'
[16:02] <fission6> thanks SpamapS 
[16:02] <fission6> 'init-checkconf uwsgi' complains there is no file
[16:03] <fission6> do i need to do 'init-checkconf uwsgi.conf'
[16:05] <SpamapS> fission6: yeah, may even want to do /etc/init/uwsgi.conf
[16:06] <fission6> yea i just tried that, ERROR: failed to ask Upstart to check conf file
[16:10] <fission6> SpamapS: http://dpaste.org/NuSvR/
[16:10] <SpamapS> fission6: I've not used init-checkconf much.. so forgive me for not knowing how to address that :-P
[16:18] <fission6> hmm maybe someone else knows, seems like it would be fundemental issue
[16:23] <fission6> SpamapS: how do you check if your upstart script works then?
[16:27] <SpamapS> fission6: start it
[16:27] <SpamapS> fission6: errors will show up in syslog
[16:29] <fission6> nice thnaks
[18:16] <fission6> am i going to get burnt if i upgrade from 1.3 to 1.4
[19:32] <fission6> is symlinking from etc/init/ to a folder iwth a conf a bad idea?
[20:04] <fission6> can you symblink to a upstart from /etc/init
[20:19] <SpamapS> fission6: no
[20:19] <SpamapS> fission6: for a number of reasons, the files need to be there, on the root disk, in /etc/init
[20:33] <fission6> ok
[20:55] <fission6> any ideas why restart for my job doesn;t work but start and stop do
[21:09] <SpamapS> fission6: the upstart restart command is.. a little weird
[21:10] <SpamapS> fission6: if you use 'service foo restart', that should do a stop/start
[21:18] <fission6> really?
[21:18] <fission6> whats up with that, let me try
[21:20] <fission6> did not work
[21:20] <fission6> i find htis weird, would have though it just does a stop start, which both work
[21:26] <SpamapS> fission6: it does, but it does it really fast, and without running post-stop
[21:26] <SpamapS> or pre-stop, I forget
[21:26] <SpamapS> fission6: anyway, its possible you need a post-stop which makes sure your service is dead
[21:34] <fission6> ?
[21:34] <fission6> seems odd 
[21:34] <fission6> and convoluted
[22:29] <fission6> SpamapS: can you start multiple processes with a single conf?
[22:52] <SpamapS> fission6: yes, through use of the instance keyword
[22:56] <fission6> i want to be clear SpamapS i want to start two seperate daemons, one to start a queueing peice and one for uwsgi 
[22:58] <SpamapS> fission6: ah, make that two .confs then
[22:58] <SpamapS> fission6: one can be 'start on started x' and 'stop on stopping x' so they'll act as one.
[22:59] <SpamapS> fission6: though IMO, its better to have things de-coupled unless they absolutely must be coupled
[22:59] <fission6> hm
[22:59] <fission6> i'd prefer a master script to start up the queying celeryd process then uwsgi web app process
[23:00] <fission6> i'd prefer one conf
[23:01] <SpamapS> how are they related? sounds like they aren't.
[23:01] <fission6> SpamapS: ^
[23:01] <fission6> welll one wouldn't run without the other
[23:01] <fission6> celery does all the tasks associated with the web app uwsgi, such as email sending
[23:02] <SpamapS> you can have 1 conf, but you'll have to use pidfiles and daemonize things yourself
[23:03] <fission6> so you can't have multiple 'exec' or multiple script stanzas?
[23:03] <SpamapS> fission6: 2 confs has some real advantages. For instance, when the uwsgi segfaults, respawn can start it back up again.. it doesn't have to then stop celery, then start them both... which is more complicated and error prone
[23:05] <fission6> so maybe 2 scripts and 1 maste script to start each on of them?
[23:07] <JanC> upstart .conf files aren't scripts, they are configuration files  ☺
[23:08] <JanC> if one of the two processes depends on the other, then you define such a dependency in the configuration of those jobs, otherwise you just start them in parallel...
[23:09] <fission6> so it sounds like what i am doing shouldn't be done in one sript
[23:09] <fission6> err conf file
[23:10] <JanC> most likely not
[23:10] <fission6> JanC: do you work with web apps by chance and Upstart confs, whats the nature of most of the confs
[23:10] <ee99ee> Hi, I'm having a problem where this script is hanging after "start myapp": http://pastebin.com/nXSd79yP
[23:11] <ee99ee> when I run the command (minus "exec" of course) manually, it starts up just fine, so I know the command is at least correct
[23:11] <ee99ee> I've tried expect in all 3 modes, and it doesn't affect it in any way
[23:11] <ee99ee> suggestions?
[23:11] <JanC> fission6: I currently don't really work with webapps that need their own upstart jobs, no
[23:14] <ee99ee> is there a way to mayb debug that it's even getting to that point?
[23:14] <ee99ee> or see what's going on at all?
[23:14] <ee99ee> because "start myapp" just goes to a new line and hangs
[23:15] <fission6> maybe look into syslog
[23:15] <JanC> you can enable logging (in recent upstart versions)
[23:16] <JanC> per-job logging actually
[23:16] <ee99ee> hmm
[23:16] <JanC> logging for upstart itself can also be enabled with a kernel parameter or using initctl
[23:18] <JanC> oh, and I think when using start-stop-daemon, yous certainly don't want to use expect fork/daemon
[23:18] <ee99ee> I tried commenting it out too
[23:20] <JanC> well, you probably don't want to use the --background option for start-stop-daemon
[23:20] <ee99ee> ok let me try that
[23:21] <ee99ee> same thing
[23:21] <JanC> as the manpage says, you should use that only in a last resort  ☺
[23:21] <ee99ee> yeah :-/
[23:22] <fission6> why is exec used in script stanza?
[23:22] <ee99ee> instead of script stanza, you mean?
[23:24] <JanC> the 1st respawn line is also obsolete of course
[23:25] <ee99ee> ahh, thanks
[23:26] <JanC> you might also want to check the logs of the application
[23:27] <ee99ee> the application isn't even being started... I looked, but there isn't even a process for the app in the process list
[23:27] <fission6> why do they use exec with two differnt meanings
[23:27] <JanC> fission6: eh?
[23:27] <fission6> exec in a script stanza and exec outside ofi t or does it do the same thing
[23:28] <ee99ee> I think it does the same thing
[23:28] <JanC> exec inside a script does not have anything to do with upstart
[23:28] <fission6> right. why do "we" use it then to kick off the main daemon your are upstarting
[23:28] <JanC> it does whatever your shell does with the exec command
[23:29] <fission6> right, so do i need it in an upstart script, seems its used as a standard but i dont see what it does
[23:29] <fission6> also still unclear why i cant run multiple things in a conf
[23:31] <JanC> you can run multiple things from one conf
[23:31] <JanC> but it won't supervise them separately then
[23:32] <fission6> JanC: one other issue i have is i cn cleanly start and stop my service but i can not restart it, it stops but doesn't restart
[23:33] <JanC> as SpamapS said, that probably means it tries to restart it too quickly
[23:33] <fission6> ok. so what does that mean in terms of resolving it, seems like an odd issue
[23:34] <JanC> if you use start-stop-daemon, it offers some ways to deal with that
[23:34] <fission6> this whole thing is becoming such a tangled mess just to get uwsgi to restart when my ec2 reboots
[23:34] <ee99ee> fission6: I feel your pain
[23:35] <ee99ee> JanC: do you have an example of a start-stop-daemon implmentation
[23:35] <JanC> or otherwise you might need some custom pre-stop or post-stop script or so
[23:36] <fission6> yea sort of odd was hoping upstart was a bit cleaner, looks like supervisord is a bit easier
[23:43] <JanC> fission6: I find upstart rather easy to understand, it's usually more work to understand how the applications that it needs to start/stop/etc. work  ;)
[23:44] <fission6> well when it starts before something stops its a bit retarded, especially when its managing the process
[23:45] <JanC> yes/no
[23:46] <JanC> it's difficult to tell when an application starts & stops, or to be more exact: when it stopped "enough" that you can (re)start it  ☺
[23:46] <SpamapS> fission6: IMO, you are coupling things that don't need to be coupled
[23:47] <SpamapS> fission6: just start celery and the webapp service on their own. They'll talk if they can.
[23:47] <SpamapS> fission6: this will make it easier to split out the two into dedicated services later on anyway
[23:47] <JanC> well, unless the webapp really needs celery, then you make it wait on celery...
[23:48] <JanC> in both cases, you want 2 jobs
[23:49] <fission6> thats fine, i agree on tht front
[23:49] <fission6> i dont like how i can not currently restart uwsgi when before i got into upstart i woudl jsut stop adn start the process via control - c in a screen window
[23:50] <fission6> can we focus on why restart isn't working, maybe getting thatin place will make me happy
[23:51] <fission6> this is my uwsgi.conf to be clear http://dpaste.org/w1FBw/
[23:53] <fission6> SpamapS: JanC could this be why http://projects.unbit.it/uwsgi/wiki/Upstart read the --die-on-term section
[23:54] <SpamapS> fission6: is your uwsgi service printing errors? I bet its trying to LISTEN on a taken port because the OS hasn't given back the socket yet.
[23:55] <fission6> nah
[23:55] <fission6> By default sending SIGTERM to uWSGI would mean "brutally-reload-it", while normally apps tend to shutdown on SIGTERM. To shutdown uWSGI use SIGINT or SIGQUIT. If you cannot live with such setup you can use --die-on-term option.
[23:55] <fission6> this could be it
[23:56] <JanC> that might indeed be the reason
[23:56] <SpamapS> wow, what an abuse of SIGTERM
[23:57] <JanC> ☺
[23:57] <SpamapS> TERM is for *TERMINATING* not reloading
[23:57] <JanC> well, depends on how uwsgi works
[23:57] <fission6> my guess is its problem the reason since i only see --die-on-term mentioned in the upstart docs http://projects.unbit.it/uwsgi/wiki/Upstart
[23:57] <SpamapS> a process that doesn't exit very soon after SIGTERM is going to get a SIGKILL soon after from some overzealous BOFH
[23:57] <JanC> maybe it has a master process that automatically restarts child processes that get terminated or the like
[23:57] <SpamapS> fission6: yes you want --die-on-term
[23:58] <SpamapS> and you should send a really nasty email to the uwsgi authors explaining how dumb this is
[23:58] <SpamapS> we have HUP for reloads... anything further, use USR1
[23:58] <SpamapS> fission6: you can also use 'kill signal QUIT' I think
[23:59] <SpamapS> sort of 6 and 1/2 dozen at that point
[23:59] <SpamapS> ugh, and it also doesn't realize that Upstart has had socket activation since 10.04
[23:59] <fission6> when you say "we have"