I'm trying to host a Discord Bot with a free dyno of Heroku, for some reason I'm getting this problem.
2020-07-28T07:37:50.141832+00:00 heroku[worker.1]: Starting process with command `node src/link_bot.js`
2020-07-28T07:37:50.802589+00:00 heroku[worker.1]: State changed from starting to up
2020-07-28T07:37:50.815799+00:00 heroku[worker.1]: Idling
2020-07-28T07:37:50.819227+00:00 heroku[worker.1]: State changed from up to down
2020-07-28T07:37:50.827486+00:00 heroku[worker.1]: Idling because quota is exhausted
2020-07-28T07:37:57.010586+00:00 app[worker.1]: Error waiting for network: Resource temporarily unavailable
Why is this happening? What can I do?
Dyno free hours are over. You have to wait until another month, then they will renew.
Related
I am hosting an API on heroku. When i try to run that i get this error message
2020-09-29T09:12:10.860262+00:00 heroku[web.1]: State changed from up to down
2020-09-29T09:12:10.866747+00:00 heroku[web.1]: Idling because quota is exhausted
2020-09-29T09:12:11.906319+00:00 heroku[web.1]: Stopping all processes with SIGTERM
2020-09-29T09:12:11.997631+00:00 heroku[web.1]: Process exited with status 143
I do not know why can you please help me?
My procfile is:web:node ./index.js
The cause is in the error log: Idling because quota is exhausted
In the Free plan you are entitled to 550 hrs free, which can become 1000hrs if you register a valid credit card. See Heroku reference
Adding a CreditCard it would allow to run your app without downtime.
I have a Heroku free web app which was working nicely with my initial testing, but with a bigger test it just crashed:
2020-06-17T21:45:10.068131+00:00 app[web.1]: my last console.log message
2020-06-17T21:46:39.334604+00:00 heroku[web.1]: Idling
2020-06-17T21:46:39.336851+00:00 heroku[web.1]: State changed from up to down
2020-06-17T21:46:40.202867+00:00 heroku[web.1]: Stopping all processes with SIGTERM
2020-06-17T21:46:40.240320+00:00 heroku[router]: at=info method=GET path="/sockjs/432/q7l5m7n6/websocket" host=not-my-real-app.herokuapp.com request_id=ec5f9418-fe2b-4b50-8f92-fb59e315f2ce fwd="CLIENT-IP" dyno=web.1 connect=0ms service=2415813ms status=101 bytes=175 protocol=https
2020-06-17T21:46:40.240323+00:00 heroku[router]: at=info method=GET path="/sockjs/106/0_a5cq0q/websocket" host=not-my-real-app.herokuapp.com request_id=5ca1d1cb-03d4-4107-887b-a206449692c7 fwd="CLIENT-IP" dyno=web.1 connect=0ms service=2321844ms status=101 bytes=175 protocol=https
+12 other similar messages, one per browser window connected
2020-06-17T21:46:40.288644+00:00 heroku[web.1]: Process exited with status 143
2020-06-17T21:46:40.451795+00:00 heroku[web.1]: Unidling
2020-06-17T21:46:40.459070+00:00 heroku[web.1]: Unidling
2020-06-17T21:46:40.464243+00:00 heroku[web.1]: State changed from down to starting
2020-06-17T21:46:40.469937+00:00 heroku[web.1]: Unidling
The logs seem to indicate that the dyno was stopped by Heroku. This was some time into my first test with many (14) simultaneous web clients connections, so it wasn't idle (certainly not for 30 minutes), and I have plenty (989.08) of free dyno hours remaining.
Do you know why my app might have been killed? I could upgrade to a hobby account, but I don't know if that would help.
Or could it be a crash of my application code, despite what the logs seem to show?
Details:
Free web dyno
mLab MongoDB add-on
Region: Europe
Stack: heroku-18
Framework: Node.js
Slug size: 47.2 MiB of 500 MiB
After testing this out many times, I found that Heroku killed my Dyno after 34:41 to 38:25 (mins:secs) from when it was started ("Unidling" to "Idling" messages). According to the documentation, it should only do this for idle Dynos. Each time I was using it throughout the ~35 minutes, ie. open connections, server activity (evidenced by console.log messages in the server log), and client-server traffic.
I switched to a "Hobby" type Dyno, and after that they ran uninterrupted. I just used it for 2 hours without trouble, and have tested it left idle overnight.
I can understand Heroku having a restriction on free apps, but these should be accurately documented. It does not speak well for their reliability as a hosting service that they kill Dynos without explanation or notification (as far as I can see). For me this is an ugly stain on their otherwise excellent service.
Here is the error:
Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
Analyzing the log, I noticed that every time I 'run' the app on Heroku it directs to a different port.
I have already encountered numerous examples of how to solve this, but using Express and not explicitly using AdonisJS (which I am finding very limited).
Another issue I have is the use of the domain for my application, should the be the same as the Heroku provides or localhost (127.0.0.1)?
My log:
2019-03-28T12:54:19.688098+00:00 app[web.1]: info: serving app on http://127.0.0.1:48470
2019-03-28T12:55:17.075091+00:00 heroku[web.1]: State changed from starting to crashed
2019-03-28T12:55:17.081028+00:00 heroku[web.1]: State changed from crashed to starting
2019-03-28T12:55:16.883066+00:00 heroku[web.1]: Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
2019-03-28T12:55:16.883174+00:00 heroku[web.1]: Stopping process with SIGKILL
2019-03-28T12:55:17.056876+00:00 heroku[web.1]: Process exited with status 137
2019-03-28T12:55:20.176409+00:00 heroku[web.1]: Starting process with command `ENV_SILENT=true npm start`
2019-03-28T12:55:22.553527+00:00 app[web.1]:
2019-03-28T12:55:22.553548+00:00 app[web.1]: > adonis-api-app#4.1.0 start /app
2019-03-28T12:55:22.553551+00:00 app[web.1]: > node server.js
2019-03-28T12:55:22.553552+00:00 app[web.1]:
2019-03-28T12:55:23.598805+00:00 app[web.1]: info: serving app on http://127.0.0.1:37943
2019-03-28T12:56:20.763929+00:00 heroku[web.1]: State changed from starting to crashed
2019-03-28T12:56:20.660053+00:00 heroku[web.1]: Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
2019-03-28T12:56:20.660202+00:00 heroku[web.1]: Stopping process with SIGKILL
2019-03-28T12:56:20.747895+00:00 heroku[web.1]: Process exited with status 137
2019-03-28T12:56:23.940320+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/" host=***** protocol=https
2019-03-28T13:21:40.085858+00:00 heroku[web.1]: State changed from crashed to starting
2019-03-28T13:21:43.920685+00:00 heroku[web.1]: Starting process with command `ENV_SILENT=true npm start`
2019-03-28T13:21:46.419408+00:00 app[web.1]:
2019-03-28T13:21:46.419429+00:00 app[web.1]: > adonis-api-app#4.1.0 start /app
2019-03-28T13:21:46.419431+00:00 app[web.1]: > node server.js
2019-03-28T13:21:46.419433+00:00 app[web.1]:
2019-03-28T13:21:47.899057+00:00 app[web.1]: info: serving app on http://127.0.0.1:51104
My .env file:
HOST=127.0.0.1
PORT=8080
NODE_ENV=development
APP_NAME=AdonisJs
APP_URL=https://${HOST}:${PORT}
APP_KEY=*******
How to prevent the port from being changed?
There are a few things going on here.
Configuration from the environment
There are two main benefits to configuring your application from the environment:
It makes configuration environment-specific, e.g. so you can use different databases, mail servers, etc. in development from the ones you use in production
It lets you keep sensitive values like API keys and passwords out of your codebase
Including your .env file in your repository negates both of these benefits. It's fine to use one in development, and it can be a convenient way to set environment variables, but it shouldn't be committed to your repository or used in Heroku.
Heroku natively supports configuration from the environment. You can set variables in the web UI or via heroku:config on the command line. This is where your environment variables should go in production.
I strongly urge you to remove your .env file from your repository with
git rm --cached .env
add it to your .gitignore, and use Heroku's native environment-based configuration instead. You should also invalidate any API keys or passwords that are contained in that file and generate new ones.
For what it's worth, the AdonisJS documentation agrees with this approach:
The .env file should never be committed to your source control or shared with other people.
Different ports
This is entirely expected:
On Heroku, apps are completely self-contained and do not rely on runtime injection of a webserver into the execution environment to create a web-facing service. Each web process simply binds to a port, and listens for requests coming in on that port. The port to bind to is assigned by Heroku as the PORT environment variable.
Heroku tells you which port to bind to via the PORT environment variable, and you must use it. But this isn't the port that will be visible externally; the standard HTTP ports will be routed to your application automatically.
IP addresses
Your application should listen on all IP addresses. If you're using Express, I think that means you don't provide an IP address in your .listen() call. You should only provide the port there, and that port should come from the PORT environment variable.
heroku logs
2018-04-20T20:45:50.151330+00:00 app[api]: Enable Logplex by user ghsklat2378123#gmail.com
2018-04-20T20:45:50.059558+00:00 app[api]: Release v1 created by user ghsklat2378123#gmail.com
2018-04-20T20:45:50.059558+00:00 app[api]: Initial release by user ghsklat2378123#gmail.com
2018-04-20T20:45:50.151330+00:00 app[api]: Release v2 created by user ghsklat2378123#gmail.com
2018-04-20T20:46:48.000000+00:00 app[api]: Build started by user ghsklat2378123#gmail.com
2018-04-20T20:46:58.098188+00:00 app[api]: Deploy 2b289e67 by user ghsklat2378123#gmail.com
2018-04-20T20:46:58.098188+00:00 app[api]: Release v3 created by user ghsklat2378123#gmail.com
2018-04-20T20:46:48.000000+00:00 app[api]: Build succeeded
2018-04-20T20:46:58.115335+00:00 app[api]: Scaled to web#1:Free by user ghsklat2378123#gmail.com
2018-04-20T20:47:00.895268+00:00 heroku[web.1]: Starting process with command `npm start`
2018-04-20T20:47:03.518908+00:00 app[web.1]:
2018-04-20T20:47:03.518933+00:00 app[web.1]: > node server.js
2018-04-20T20:47:03.518931+00:00 app[web.1]: > stywqrrd#1.0.0 start /app
2018-04-20T20:47:03.518935+00:00 app[web.1]:
2018-04-20T20:47:03.875652+00:00 app[web.1]: Express server listening on port 3000
2018-04-20T20:48:01.013365+00:00 heroku[web.1]: Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
2018-04-20T20:48:01.013866+00:00 heroku[web.1]: Stopping process with SIGKILL
2018-04-20T20:48:01.152301+00:00 heroku[web.1]: State changed from starting to crashed
2018-04-20T20:48:01.155261+00:00 heroku[web.1]: State changed from crashed to starting
2018-04-20T20:48:01.132422+00:00 heroku[web.1]: Process exited with status 137
2018-04-20T20:48:02.894892+00:00 heroku[web.1]: Starting process with command `npm start`
2018-04-20T20:48:05.106690+00:00 app[web.1]:
2018-04-20T20:48:05.106708+00:00 app[web.1]: > sstywqrrd#1.0.0 start /app
2018-04-20T20:48:05.106710+00:00 app[web.1]: > node server.js
2018-04-20T20:48:05.106712+00:00 app[web.1]:
2018-04-20T20:48:05.295340+00:00 app[web.1]: Express server listening on port 3000
This is a very simple node app that i'm unable to deploy. When I got the link it displays:heroku welcome to you new app. Refer to documentation if you need help deploying. Logs don't show any error(all logs shown in blue color). How do I solve this?
Cloned the repo and then did
git init, git add, git commit
heroku create
heroku git:remote -a safe-forest-59278
heroku apps:create myappName
git push heroku master
According to log statement
Error R10 (Boot timeout) -> Web process failed to bind to $PORT
within 60 seconds of launch
This simply means that the port your are trying to connect with is not available for some reason.
And most probably you're specifying the port like
port = 3000
You should change this line to
port = process.env.PORT || 3000
This will let heroku servers to assign an available port to your server to listen to.
Why this happens is because mostly the ports that you specify while developing an application, there are very rare chances for that ports to be available and open in production.
After booting up my Node.js Heroku app with this Procfile:
web: node www/main.js
I used to get:
Error R10 (Boot timeout) -> Web process failed to bind to $PORT within
60 seconds of launch
So I have changed my Procfile to a generic command to get around this, following from here, using:
start: node www/main.js
And I am still getting a shut down after 60 seconds. This is the error(s) now:
2015-01-20T13:04:01.452819+00:00 heroku[worker.1]: State changed from
up to starting
2015-01-20T13:04:02.728905+00:00 heroku[worker.1]: State changed from starting to down
2015-01-20T13:04:03.434251+00:00 heroku[worker.1]: Starting process with command node www/main.js
2015-01-20T13:04:03.874370+00:00 heroku[worker.1]: Stopping all processes with SIGTERM
2015-01-20T13:04:05.188100+00:00 heroku[worker.1]: Process exited with status 143
2015-01-20T13:04:05.930916+00:00 app[worker.1]: [Tue Jan 20 2015 13:04:05 GMT+0000 (UTC)] INFO Connecting...
2015-01-20T13:04:06.837197+00:00 app[worker.1]: Welcome to Slack. You are #derpy of
2015-01-20T13:04:06.837559+00:00 app[worker.1]: You are in: #general
2015-01-20T13:04:06.837637+00:00 app[worker.1]: As well as:
2015-01-20T13:04:06.837739+00:00 app[worker.1]: You have 13 unread messages
2015-01-20T13:04:07.526373+00:00 heroku[worker.1]: Error R12 (Exit timeout) -> At least one process failed to exit within 10 seconds of
SIGTERM
2015-01-20T13:04:07.526508+00:00 heroku[worker.1]: Stopping remaining processes with SIGKILL
I am using https://github.com/slackhq/node-slack-client and have not adapted the code too much. I have tried all the usual things and now I'm asking for help.
The other weird thing is that the Slack bot connects and is running perfectly for those 60 seconds.
socket = io.listen(process.env.PORT);
Do this in your main.js file, and revert back to web: node www/main.js