Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jekyll 2.5.3 does not work on Heroku #3907

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

Jekyll 2.5.3 does not work on Heroku #3907

schneems opened this issue Aug 11, 2015 · 18 comments

Comments

@schneems
Copy link
Contributor

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
Copy link
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
Copy link
Contributor Author

Good catch, i'll give that a try.

@parkr
Copy link
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 as completed Aug 12, 2015
@schneems
Copy link
Contributor Author

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
Copy link
Contributor

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

@schneems
Copy link
Contributor Author

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
Copy link
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.

@envygeeks
Copy link
Contributor

Or I might just build a jekyll/heroku image.

@parkr
Copy link
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
Copy link
Contributor Author

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
Copy link
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.

@schneems
Copy link
Contributor Author

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
Copy link
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?

@envygeeks
Copy link
Contributor

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

@schneems
Copy link
Contributor Author

@envygeeks
Copy link
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)

@schneems
Copy link
Contributor Author

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
Copy link
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.
Projects
None yet
Development

No branches or pull requests

4 participants