@angelo: what I do in these situations is (1) make my node app dependent on the database service start (which you already have) and (2) make my webapp probe for the database actually responding before opening up connections for user sessions.
This can be done in many ways. My first approach was to put the probing and app.listen in separate steps of a node-nimble set of serialized tasks. Another approach is to put the probing in some app.use middleware which holds things up until either the database responds or exceeds a timeout. I'm not sure how helpful this will be, but as long as your routes are all fault-tolerant, maybe the worst thing which happens is the first few requests fail and users get a message to try again later... And if anyone has different or better ideas, I'd like to learn from them! On Feb 20, 2012 4:44 AM, "Angelo Chen" <[email protected]> wrote: > Hi, > > Thanks for sharing the script, that works. > one thing, say your app will connect to redis like those using coffee- > resque, it will try to connect to redis-server once loaded, and yet at > that time, redis is not yet ready, so you got those exceptions, > putting this might not be absolute sure it will work: > > start on started redis > > what I'm doing now is, delay the worker from start up for a few > seconds: > > setTimeout(function() { > worker.start() > }, 8000) > > works, but still got a lot of exceptions, any other way? > > > On Feb 20, 3:36 am, "C. Mundi" <[email protected]> wrote: > > On Sat, Feb 18, 2012 at 8:49 AM, Angelo Chen <[email protected] > >wrote: > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > with following upstart script, I can do: /sbin/start testjs and /sbin/ > > > stop testjs, but it will not start when boot up pc, why? > > > > > #!upstart > > > description "node.js server" > > > author "jmmmm" > > > > > start on startup > > > stop on shutdown > > > > > script > > > export HOME="/root" > > > > > exec /usr/local/bin/node /root/test.js 2>&1 >> /var/log/node.log > > > end script > > > > > -- > > > Job Board:http://jobs.nodejs.org/ > > > Posting guidelines: > > >https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > > > You received this message because you are subscribed to the Google > > > Groups "nodejs" group. > > > To post to this group, send email to [email protected] > > > To unsubscribe from this group, send email to > > > [email protected] > > > For more options, visit this group at > > >http://groups.google.com/group/nodejs?hl=en?hl=en > > > > What mscdex said. Upstart is a wonderful tool: > http://upstart.ubuntu.com/ > > Here's an example of how I use upstart on Ubunutu. The following script > is > > coincidentally very similar to one by Tim Smart ( > http://howtonode.org/deploying-node-upstart-monit) which I'd like to > > acknowledge here even if all it proves is that most upstart scripts look > > very similar. > > > > *file: /etc/init/node-webapp.conf* > > # node-webapp service > > > > description "node.js webapp" > > author "cmundi" > > > > emits node-webapp-up > > emits node-webapp-down > > > > start on (net-device-up > > and local-filesystems > > and runlevel [2345]) > > > > stop on runlevel [!2345] > > > > respawn > > respawn limit 10 5 > > > > script > > export HOME="/home/cmundi/node/apps" > > echo $$ > /var/run/node-webapp.pid > > exec sudo -u root /usr/local/bin/node $HOME/webapp.js >> > > /var/log/node-webapp.sys.log 2>&1 > > end script > > > > pre-start script > > echo "`date -u` Starting" >> /var/log/node-webapp.sys.log > > end script > > > > post-start script > > initctl emit node-webapp-up > > end script > > > > pre-stop script > > echo "`date -u` Stopping" >> /var/log/node-webapp.sys.log > > rm /var/run/node-webapp.pid > > end script > > > > post-stop script > > initctl emit node-webapp-down > > end script > > > > A few things to notice. I like to start and stop on specific runlevel > > events instead of higher-level 'startup' and 'shutdown' events, just as a > > matter of personal taste. Call me crazy, but I also like to make sure > > networking is up and local filesystems are mounted before I try to start > > node. I also emit my own -up and -down events so that other upstart jobs > > can be triggered, for example monitoring the server, providing a test > > harness or mock database or whatever. (But naturally you must not assume > > that your node app is listening just because node started!) > > > > There are a few threads and blogs (including Tim Smart's, linked above) > > which suggest using monit instead of the respawn capability of upstart. > > Monitoring server health is good. And although I use upstart to respawn > a > > completely dead server, I prefer not to automatically restart a running > but > > nonresponsive server. Although I can't do much about a dead server, > except > > hope that my logs were informative, I often can learn a lot from a > > non-responsive server by watching/probing it while it is struggling. > ymmv. > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
