Keep a node application running on azure app service

Question

I have deployed a node js web application on app service in azure. Issue is that my application occasionally getting killed for unknown reason. I have done exhaustive search through all the log fines using kudu.

If I restart app service, application starts working.

Is there any way I can restart my node application once it has crashed. Kind of run for ever no matter what. For example if any error happens in an asp.net code deployed in IIS, IIS never crashes, its keeps of serving other incoming request.

Something like using forever/pm2 in azure app service.

Kanarese

Answer 1

node.js in Azure App Services is powered by IISNode, which takes care of everything you described, including monitoring your process for failures and restarting it.

Consider the following POC:

var http = require('http');    
http.createServer(function (req, res) {
    if (req.url == '/bad') {
        throw 'bad';
    }
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end('bye');
}).listen(process.env.PORT || 1337);

If I host this in a Web App and issue the following sequence of requests:

1. GET /
2. GET /bad
3. GET /

Then the first will yield HTTP 200, the second will throw on the server and yield HTTP 500, and the third will yield HTTP 200 without me having to do anything. IISNode will just detect the crash and restart the process.

So you shouldn't need PM2 or similar solution because this is built in with App Services. However, if you really want to, they now have App Services Preview on Linux, which is powered by PM2 and lets you configure PM2. More on this here. But again you get this out of the box already.

Another thing to consider is Always On setting which is on by default:

By default, web apps are unloaded if they are idle for some period of time. This lets the system conserve resources. In Basic or Standard mode, you can enable Always On to keep the app loaded all the time. If your app runs continuous web jobs, you should enable Always On, or the web jobs may not run reliably.

This is another possible root cause for your issue and the solution is to disable Always On for your Web App (see the link above).

Calculous

Not sure whats the issue. Does not look like iisnode is restarting automatically – Kanarese

try to enable verbose logging and monitor the console output via the log streaming option in the Web App – Calculous

Does this answer your original question? If so, please mark as answer – Calculous

Unfortunately with verbose enabling, not getting any helpful information. Still looking for the solution – Kanarese

Solution to what..? your question is around detecting failures in node.exe and restarting automatically, right? – Calculous

yes, once down its not starting again. I need to manually restart app service to get node server started – Kanarese

what makes your process go down? – Calculous

thats the problem, log does not give useful information. Application log in enabled and I have checked logging-errors.txt for information – Kanarese

is everything on verbose? How do you know your process is crashing, what's the symptom? – Calculous

Is there any documentation for IISnode that describes the auto-restart feature upon crashing? – Vannoy

Answer 2

I really want to thank itaysk for your support for this issue.

Issue was not what I was suspecting. Actually the node server was getting restarted on failure correctly.

There was a different issue. Why my website was getting non responsive is for a different reason. Here is what was happening-

We have used rethinkdbdash to connect to rethinkdb database and we was using connection pool. There was a coding/design issue. We have around 15 change feeds implemented with along with socket.io. And the change feed was getting initialised for every user logged in. This was increasing number of active connections in the pool. And rethinkdbdash has default limit of 1000 connection in the pool and as there were lots of live connections, all the available connection in the pool was getting exhausted resulting no more available connection. So, request was waiting for an open connection and it was not getting any available, hence waiting for ever blocking any new requests to be served.

Kanarese