@chris: yes. My upstart conf file (not a script per se but that's semantics) sends both stdout and stderr to a conventional /var/log/whatever.log file. If they didn't, they'd be useless to me and I would fix them. :)
Be sure in your upstart script to exec node as a user with privileges to write to the log file. On Feb 20, 2012 11:19 PM, "Chris Dew" <[email protected]> wrote: > Do any of these scripts *successfully* capture stdout and stderr? I > have used variations on these but just end up with zero length log > files ( the log file is created ). > > Thanks, > > Chris. > > On Feb 21, 3:58 am, "C. Mundi" <[email protected]> wrote: > > @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 > -- 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
