Jekyll 2.5.3 does not work on Heroku #3907

Closed
schneems opened this Issue Aug 11, 2015 · 18 comments

Comments

Projects
None yet
4 participants
@schneems
Contributor

schneems commented Aug 11, 2015

Not getting any error messages or whatnot, it's just not binding to a port

Configuration file: /app/_config.yml
2015-08-11T16:58:20.608067+00:00 app[web.3]:   Server running... press ctrl-c to stop.
2015-08-11T16:58:20.607782+00:00 app[web.3]:     Server address: http://127.0.0.1:8656//
2015-08-11T16:58:20.775932+00:00 app[web.4]:                     done.
2015-08-11T16:58:20.775941+00:00 app[web.4]:  Auto-regeneration: disabled. Use --watch to enable.
2015-08-11T16:58:20.777247+00:00 app[web.4]: Configuration file: /app/_config.yml
2015-08-11T16:58:20.836243+00:00 app[web.4]:   Server running... press ctrl-c to stop.
2015-08-11T16:58:20.835635+00:00 app[web.4]:     Server address: http://127.0.0.1:16072//
2015-08-11T16:59:01.756207+00:00 heroku[router]: at=error code=H20 desc="App boot timeout" method=GET path="/" host=www.schneems.com request_id=fddf674c-d80a-4b47-95f9-8c425419ec40 fwd="72.48.77.213" dyno= connect= service= status=503 bytes=
2015-08-11T16:59:02.148184+00:00 heroku[router]: at=error code=H20 desc="App boot timeout" method=GET path="/" host=www.schneems.com request_id=eda81101-d353-4b06-b982-24db71618df4 fwd="72.48.77.213" dyno= connect= service= status=503 bytes=
2015-08-11T16:59:13.556742+00:00 heroku[web.2]: Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
2015-08-11T16:59:13.556830+00:00 heroku[web.2]: Stopping process with SIGKILL
2015-08-11T16:59:13.697709+00:00 heroku[web.1]: Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
2015-08-11T16:59:13.697981+00:00 heroku[web.1]: Stopping process with SIGKILL
2015-08-11T16:59:14.549937+00:00 heroku[web.2]: State changed from starting to crashed
2015-08-11T16:59:14.695724+00:00 heroku[web.1]: Process exited with status 137
2015-08-11T16:59:14.534318+00:00 heroku[web.2]: Process exited with status 137
2015-08-11T16:59:14.709574+00:00 heroku[web.1]: State changed from starting to crashed
2015-08-11T16:59:16.133399+00:00 heroku[web.4]: Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
2015-08-11T16:59:16.133399+00:00 heroku[web.4]: Stopping process with SIGKILL
2015-08-11T16:59:16.684057+00:00 heroku[web.3]: Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
2015-08-11T16:59:16.684057+00:00 heroku[web.3]: Stopping process with SIGKILL
2015-08-11T16:59:16.987825+00:00 heroku[web.4]: State changed from starting to crashed
2015-08-11T16:59:16.975855+00:00 heroku[web.4]: Process exited with status 137
2015-08-11T16:59:17.618855+00:00 heroku[web.3]: Process exited with status 137
2015-08-11T16:59:17.626433+00:00 heroku[web.3]: State changed from starting to crashed
2015-08-11T16:59:18.209199+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/post/33781154129/would-you-like-a-mobile-app-with-that" host=www.schneems.com request_id=f5bc06ad-be14-4d3e-acf5-02eaaa7ad430 fwd="123.126.113.79" dyno= connect= service= status=503 bytes=
2015-08-11T16:59:18.409245+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/feed.xml" host=www.schneems.com request_id=e3de207f-35ae-414e-bfa1-98b3f7cf3c0d fwd="54.81.19.61" dyno= connect= service= status=503 bytes=
2015-08-11T16:59:19.402369+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/rss" host=www.schneems.com request_id=6d650a2a-8207-4d30-92b8-08daa295077b fwd="94.228.34.248" dyno= connect= service= status=503 bytes=

I bumped it back down to jekyll 2.4.0 and it works

2015-08-11T17:13:43.879767+00:00 heroku[web.3]: State changed from starting to up
2015-08-11T17:13:44.424971+00:00 heroku[router]: at=info method=GET path="/public/css/hyde.css" host=www.schneems.com request_id=fe180999-a19b-4f51-8314-cdd6ef653d02 fwd="72.48.77.213" dyno=web.2 connect=1ms service=5ms status=200 bytes=4526
2015-08-11T17:13:44.509608+00:00 heroku[router]: at=info method=GET path="/public/favicon.ico" host=www.schneems.com request_id=477ab996-c9ab-4dee-8b76-fbf0f26694df fwd="72.48.77.213" dyno=web.2 connect=0ms service=4ms status=200 bytes=1397
2015-08-11T17:13:45.755381+00:00 heroku[router]: at=info method=GET path="/post/25098659429/databases-rails-week-1-introduction" host=www.schneems.com request_id=77932dbf-612d-4472-9ef2-2976e210bf7b fwd="91.221.217.160" dyno=web.3 connect=1ms service=6ms status=301 bytes=386
2015-08-11T17:13:45.901473+00:00 heroku[router]: at=info method=GET path="/post/25098659429/databases-rails-week-1-introduction/" host=www.schneems.com request_id=7c3a6aaf-177e-49ab-931c-8bc53bd9efd4 fwd="91.221.217.160" dyno=web.2 connect=0ms service=4ms status=200 bytes=6458
2015-08-11T17:13:46.065554+00:00 heroku[router]: at=info method=GET path="/public/css/poole.css" host=www.schneems.com request_id=6f831d98-6fa9-4279-af35-5618fc2cbc1c fwd="91.221.217.160" dyno=web.2 connect=0ms service=3ms status=200 bytes=7108
2015-08-11T17:13:46.294482+00:00 heroku[router]: at=info method=GET path="/public/css/hyde.css" host=www.schneems.com request_id=dd40b897-1e8a-4632-ab99-dd9e8fa47638 fwd="91.221.217.160" dyno=web.3 connect=1ms service=4ms status=200 bytes=4525
2015-08-11T17:13:46.290906+00:00 heroku[router]: at=info method=GET path="/public/css/syntax.css" host=www.schneems.com request_id=b9f9a511-fb9e-4049-9797-dc8de4139fa7 fwd="91.221.217.160" dyno=web.3 connect=1ms service=5ms status=200 bytes=3721
2015-08-11T17:13:46.540398+00:00 app[web.4]:                     done.
2015-08-11T17:13:46.540413+00:00 app[web.4]:  Auto-regeneration: disabled. Use --watch to enable.
2015-08-11T17:13:46.541681+00:00 app[web.4]: Configuration file: /app/_config.yml
2015-08-11T17:13:46.594679+00:00 app[web.4]:   Server running... press ctrl-c to stop.
2015-08-11T17:13:46.594267+00:00 app[web.4]:     Server address: http://0.0.0.0:27934//
2015-08-11T17:13:46.815538+00:00 heroku[router]: at=info method=GET path="/public/favicon.ico" host=www.schneems.com request_id=502a018a-16bb-447b-a547-82adf64e7b96 fwd="72.48.77.213" dyno=web.3 connect=1ms service=5ms status=200 bytes=1396
2015-08-11T17:13:46.991992+00:00 heroku[web.4]: State changed from starting to up
2015-08-11T17:13:47.290816+00:00 heroku[router]: at=info method=GET path="/public/favicon.ico" host=www.schneems.com request_id=2e850d96-7531-400d-bf09-a6c23fb4985a fwd="91.221.217.160" dyno=web.3 connect=1ms service=17ms status=200 bytes=1396
2015-08-11T17:13:47.433173+00:00 heroku[router]: at=info method=GET path="/public/favicon.ico" host=www.schneems.com request_id=bf954453-230f-4185-894d-b8c9436d986c fwd="91.221.217.160" dyno=web.2 connect=0ms service=6ms status=304 bytes=161
2015-08-11T17:13:47.575876+00:00 heroku[router]: at=info method=GET path="/public/favicon.ico" host=www.schneems.com request_id=6d4da7ea-2c71-4473-890f-7a4281910963 fwd="91.221.217.160" dyno=web.3 connect=1ms service=4ms status=304 bytes=160
2015-08-11T17:13:50.160877+00:00 app[web.1]:                     done.
2015-08-11T17:13:50.160888+00:00 app[web.1]:  Auto-regeneration: disabled. Use --watch to enable.
2015-08-11T17:13:50.162208+00:00 app[web.1]: Configuration file: /app/_config.yml
2015-08-11T17:13:50.268832+00:00 app[web.1]:   Server running... press ctrl-c to stop.
2015-08-11T17:13:50.268194+00:00 app[web.1]:     Server address: http://0.0.0.0:28462//
2015-08-11T17:13:50.695263+00:00 heroku[web.1]: State changed from starting to up
2015-08-11T17:13:57.999561+00:00 heroku[router]: at=info method=GET path="/feed.xml" host=www.schneems.com request_id=bda95961-06c4-4026-acaa-8af319db373d fwd="54.81.19.61" dyno=web.2 connect=1ms service=4ms status=200 bytes=8270
2015-08-11T17:13:59.578457+00:00 heroku[router]: at=info method=HEAD path="/feed.xml" host=www.schneems.com request_id=d5b8e93a-68a7-44be-a70f-e01eeee79094 fwd="109.229.6.33" dyno=web.4 connect=1ms service=21ms status=200 bytes=259
2015-08-11T17:13:59.781077+00:00 heroku[router]: at=info method=GET path="/feed.xml" host=www.schneems.com request_id=8f024415-4383-415d-9a9c-ffecb06c676c fwd="109.229.6.33" dyno=web.2 connect=1ms service=4ms status=200 bytes=8270

Still no indication of why one does and the other doesn't. Any ideas?

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Aug 11, 2015

Member

The host is 127.0.0.1 in 2.5.3, maybe use --host 0.0.0.0?

Member

parkr commented Aug 11, 2015

The host is 127.0.0.1 in 2.5.3, maybe use --host 0.0.0.0?

@schneems

This comment has been minimized.

Show comment
Hide comment
@schneems

schneems Aug 11, 2015

Contributor

Good catch, i'll give that a try.

Contributor

schneems commented Aug 11, 2015

Good catch, i'll give that a try.

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Aug 12, 2015

Member

Ok, let me know if you're still having troubles. We don't really recommend using the built-in WEBrick server for production environments, though, so I'd recommend using something more robust if you have the time.

Member

parkr commented Aug 12, 2015

Ok, let me know if you're still having troubles. We don't really recommend using the built-in WEBrick server for production environments, though, so I'd recommend using something more robust if you have the time.

@parkr parkr closed this Aug 12, 2015

@schneems

This comment has been minimized.

Show comment
Hide comment
@schneems

schneems Aug 12, 2015

Contributor

I can confirm, --host 0.0.0.0 works.

https://github.com/schneems/schneems/blob/master/Procfile

I'll check internally and see if there's some reason it works with one and not the other. Did this default change in jekyll sometime?

Contributor

schneems commented Aug 12, 2015

I can confirm, --host 0.0.0.0 works.

https://github.com/schneems/schneems/blob/master/Procfile

I'll check internally and see if there's some reason it works with one and not the other. Did this default change in jekyll sometime?

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Aug 12, 2015

Contributor

Does Heroku give off a $HOST like it does a $PORT? If it does we can probably detect both easily.

Contributor

envygeeks commented Aug 12, 2015

Does Heroku give off a $HOST like it does a $PORT? If it does we can probably detect both easily.

@schneems

This comment has been minimized.

Show comment
Hide comment
@schneems

schneems Aug 12, 2015

Contributor

Doesn't look like it:

$ heroku run bash
Running `bash` attached to terminal... up, run.5531
~ $ env
TERM=xterm-256color
COLUMNS=181
DYNO=run.5531
PATH=/app/bin:/app/vendor/bundle/bin:/app/vendor/bundle/ruby/2.2.0/bin:/usr/local/bin:/usr/bin:/bin
_=/usr/bin/env
PWD=/app
LANG=en_US.UTF-8
PS1=\[\033[01;34m\]\w\[\033[00m\] \[\033[01;32m\]$ \[\033[00m\]
LINES=49
HOME=/app
SHLVL=2
GEM_PATH=/app/vendor/bundle/ruby/2.2.0:
PORT=8540
Contributor

schneems commented Aug 12, 2015

Doesn't look like it:

$ heroku run bash
Running `bash` attached to terminal... up, run.5531
~ $ env
TERM=xterm-256color
COLUMNS=181
DYNO=run.5531
PATH=/app/bin:/app/vendor/bundle/bin:/app/vendor/bundle/ruby/2.2.0/bin:/usr/local/bin:/usr/bin:/bin
_=/usr/bin/env
PWD=/app
LANG=en_US.UTF-8
PS1=\[\033[01;34m\]\w\[\033[00m\] \[\033[01;32m\]$ \[\033[00m\]
LINES=49
HOME=/app
SHLVL=2
GEM_PATH=/app/vendor/bundle/ruby/2.2.0:
PORT=8540
@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Aug 12, 2015

Contributor

We might be able to work something out for people who want to use Heroku, you guys do support Docker it looks like (if I am right?) our Docker images already shiv 0.0.0.0 as the address, I'll work out a how-to so people can use our Docker images to get onto Heroku quickly.

Contributor

envygeeks commented Aug 12, 2015

We might be able to work something out for people who want to use Heroku, you guys do support Docker it looks like (if I am right?) our Docker images already shiv 0.0.0.0 as the address, I'll work out a how-to so people can use our Docker images to get onto Heroku quickly.

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Aug 12, 2015

Contributor

Or I might just build a jekyll/heroku image.

Contributor

envygeeks commented Aug 12, 2015

Or I might just build a jekyll/heroku image.

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Aug 12, 2015

Member

Did this default change in jekyll sometime?

Yeah, this changed between 2.4.0 and 2.5.3.

Member

parkr commented Aug 12, 2015

Did this default change in jekyll sometime?

Yeah, this changed between 2.4.0 and 2.5.3.

@schneems

This comment has been minimized.

Show comment
Hide comment
@schneems

schneems Aug 14, 2015

Contributor

I got word from our runtime team it looks like 127.0.0.1 is only for internal connections, cannot be used for external communication. That's why it works on local development, but won't work when you deploy it. Looks like it was changed here #3053.

While I agree you shouldn't be running a "production" server on webrick, I would argue that it should just work (tm) out of the box for people playing around. I'm actually able to get a good amount of throughput with webrick and certainly good enough for the traffic I get, maybe a few thousand hits a day when I release an article.

It looks like rails binds to "localhost" https://github.com/rails/rails/blob/565582c0f5f1fe17357df67978e2f684db305bf9/railties/lib/rails/commands/server.rb#L27 instead of a specific ip, and this works on Heroku out of the box, and would avoid that chromium error. Would you take a PR to change this in jekyll?

Contributor

schneems commented Aug 14, 2015

I got word from our runtime team it looks like 127.0.0.1 is only for internal connections, cannot be used for external communication. That's why it works on local development, but won't work when you deploy it. Looks like it was changed here #3053.

While I agree you shouldn't be running a "production" server on webrick, I would argue that it should just work (tm) out of the box for people playing around. I'm actually able to get a good amount of throughput with webrick and certainly good enough for the traffic I get, maybe a few thousand hits a day when I release an article.

It looks like rails binds to "localhost" https://github.com/rails/rails/blob/565582c0f5f1fe17357df67978e2f684db305bf9/railties/lib/rails/commands/server.rb#L27 instead of a specific ip, and this works on Heroku out of the box, and would avoid that chromium error. Would you take a PR to change this in jekyll?

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Aug 14, 2015

Contributor

Your argument that "it should just work" is invalid with the reasons you justified later in your argument. It won't just work. localhost is a loopback interface and whether Heroku modifies that meaning on it's own systems is not relevant to the rest of the world so it wouldn't "just work" because it would still point to 127.0.0.1 for most of rest of the world. That's not a fix at all IMO.

Contributor

envygeeks commented Aug 14, 2015

Your argument that "it should just work" is invalid with the reasons you justified later in your argument. It won't just work. localhost is a loopback interface and whether Heroku modifies that meaning on it's own systems is not relevant to the rest of the world so it wouldn't "just work" because it would still point to 127.0.0.1 for most of rest of the world. That's not a fix at all IMO.

@schneems

This comment has been minimized.

Show comment
Hide comment
@schneems

schneems Aug 14, 2015

Contributor

A) I know basically nothing about DNS. Up until today I thought 127.0.0.1 and 0.0.0.0 and localhost were all synonymous. B) Someone at Heroku corrected me that "localhost" should not work since localhost would map back to the internal ip

~ $ host localhost
localhost has address 127.0.0.1
localhost has IPv6 address ::1

My argument is that rails server works out of the box, so should jekyll. Running on Heroku:

$ heroku run bash
Running `bash` attached to terminal... up, run.5014
~ $ bin/rails server -p $PORT -e $RAILS_ENV
=> Booting WEBrick
=> Rails 4.2.3 application starting in production on http://0.0.0.0:3498

It is connecting to 0.0.0.0. I'm not sure where 0.0.0.0 is coming from here, I grep-d the rails codebase and couldn't find it.

Contributor

schneems commented Aug 14, 2015

A) I know basically nothing about DNS. Up until today I thought 127.0.0.1 and 0.0.0.0 and localhost were all synonymous. B) Someone at Heroku corrected me that "localhost" should not work since localhost would map back to the internal ip

~ $ host localhost
localhost has address 127.0.0.1
localhost has IPv6 address ::1

My argument is that rails server works out of the box, so should jekyll. Running on Heroku:

$ heroku run bash
Running `bash` attached to terminal... up, run.5014
~ $ bin/rails server -p $PORT -e $RAILS_ENV
=> Booting WEBrick
=> Rails 4.2.3 application starting in production on http://0.0.0.0:3498

It is connecting to 0.0.0.0. I'm not sure where 0.0.0.0 is coming from here, I grep-d the rails codebase and couldn't find it.

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Aug 14, 2015

Contributor

Rails server works out of the box because Heroku gives it special treatment, it not only detects Rails, it has a default proc file it will supply and it used to also shiv some defaults for you that made it work better on Heroku. So I would argue that if Heroku does that for Rails it needs to do that for Jekyll instead of us doing it for Heroku because once we treat Heroku special what about the other providers?

Contributor

envygeeks commented Aug 14, 2015

Rails server works out of the box because Heroku gives it special treatment, it not only detects Rails, it has a default proc file it will supply and it used to also shiv some defaults for you that made it work better on Heroku. So I would argue that if Heroku does that for Rails it needs to do that for Jekyll instead of us doing it for Heroku because once we treat Heroku special what about the other providers?

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Aug 14, 2015

Contributor

What I am saying is, it's probably Heroku that is making that magic happen. Not Rails.

Contributor

envygeeks commented Aug 14, 2015

What I am saying is, it's probably Heroku that is making that magic happen. Not Rails.

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Aug 14, 2015

Contributor

I'll digress that to @parkr but I personally see no problem with us doing something like that since we do have the notion of JEKYLL_ENV now in 3.0.0 (I don't remember if that landed in 2.5)

Contributor

envygeeks commented Aug 14, 2015

I'll digress that to @parkr but I personally see no problem with us doing something like that since we do have the notion of JEKYLL_ENV now in 3.0.0 (I don't remember if that landed in 2.5)

@schneems

This comment has been minimized.

Show comment
Hide comment
@schneems

schneems Aug 14, 2015

Contributor

I see the buildpack as a hack that needs to know far too much about individual libraries to just get you running. For most cases we want to do the bare minimum. We want to minimize "magic" so that you get what you expect. This is why we don't inject anything into Rails 4.1+ apps, although we do write a default Procfile for you. I've spent a bunch of time working with Rails to make it easier to run on any platform not just Heroku. It is in my best interests if rails s works out of the box on every platform. In my dream world we could write out a default procfile magical server go! or something that would work on all ruby web things (cuba, sinatra, rails, merb, lotus, padrino, camping, pliny, hobo, roda, etc.) but that would be a pretty audacious task. I wonder if anyone would adopt or care if we tried to push for a universal RUBY_ENV that anyone could use to set their framework to "production" mode. I would love it if you could re-use something we already set, but obviously you wouldn't use RAILS_ENV and since you're not based on rack it might be hard to sell you to fallback on RACK_ENV which we do also set.

I think having some docs on Heroku around jekyll could be a good start. Right now it's really easy for me to use jekyll on heroku, all I need is a procfile and i'm good to go. If it starts getting more complicated in future versions, it would help to have docs. I'll bring up docs in planning.

Contributor

schneems commented Aug 14, 2015

I see the buildpack as a hack that needs to know far too much about individual libraries to just get you running. For most cases we want to do the bare minimum. We want to minimize "magic" so that you get what you expect. This is why we don't inject anything into Rails 4.1+ apps, although we do write a default Procfile for you. I've spent a bunch of time working with Rails to make it easier to run on any platform not just Heroku. It is in my best interests if rails s works out of the box on every platform. In my dream world we could write out a default procfile magical server go! or something that would work on all ruby web things (cuba, sinatra, rails, merb, lotus, padrino, camping, pliny, hobo, roda, etc.) but that would be a pretty audacious task. I wonder if anyone would adopt or care if we tried to push for a universal RUBY_ENV that anyone could use to set their framework to "production" mode. I would love it if you could re-use something we already set, but obviously you wouldn't use RAILS_ENV and since you're not based on rack it might be hard to sell you to fallback on RACK_ENV which we do also set.

I think having some docs on Heroku around jekyll could be a good start. Right now it's really easy for me to use jekyll on heroku, all I need is a procfile and i'm good to go. If it starts getting more complicated in future versions, it would help to have docs. I'll bring up docs in planning.

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Aug 15, 2015

Member

Love the idea of making it as easy as a procfile. I imagine localhost is fine. Not sure why we went from localhost to anything else. Maybe localhost on local machines wasn't fit for outside use? I can see 0.0.0.0 being good for JEKYLL_ENV=prod and 127.0.0.1 being good for JEKYLL_ENV=dev. Thanks, schneems!

Member

parkr commented Aug 15, 2015

Love the idea of making it as easy as a procfile. I imagine localhost is fine. Not sure why we went from localhost to anything else. Maybe localhost on local machines wasn't fit for outside use? I can see 0.0.0.0 being good for JEKYLL_ENV=prod and 127.0.0.1 being good for JEKYLL_ENV=dev. Thanks, schneems!

jcornelius added a commit to ninelabs/ninelabs.com that referenced this issue Oct 5, 2015

jcornelius added a commit to ninelabs/ninelabs.com that referenced this issue Oct 5, 2015

jcornelius added a commit to ninelabs/ninelabs.com that referenced this issue Oct 5, 2015

@jekyll jekyll locked and limited conversation to collaborators Feb 27, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.