freezes

[cj]

Hi,

So I'm using the current master head and have this code:

  def show
    respond_with claim do |format|
      format.pdf do
        render pdf: claim.number.gsub(/[^0-9a-z]/i, '_'), layout: 'print.html'
      end
    end
  end

and once it gets to here:

"***************\"/usr/local/bin/wkhtmltopdf\" -q        - - ***************"

It just freezes. When I kill the server with ctrl + c it then renders the pdf.... any ideas on what's going wrong?

Many thanks

p.s. I'm using the latest home brew version /usr/local/Cellar/wkhtmltopdf/0.11.0_rc1

[cj]

So I found out something very strange, it's showing the wkhtmltopdf bin icon in the dock and when I click on it then it completes generating the pdf. I'm using mac osx 10.7.3....

[bradjmiller]

I can verify the exact same behaviour with OS X 10.7.4.

[mech]

I encounter this issue with OS X 10.7.4 and 0.10.0 rc2 (but strangely brew said I install 0.11.0_rc1, but the command line version is 0.10)

Only after you the process icon on the "dock" will it quickly render and exit.

[cdmwebs]

+1 on 10.7.4 and /usr/local/Cellar/wkhtmltopdf/0.11.0_rc1/bin/wkhtmltopdf.

[beerlington]

This issue isn't specific to wicked_pdf, I'm having the same problem with PDFKit. The problem didn't appear until I installed 0.11.0_rc1 via homebrew. I stumbled on this ticket while trying to track down whether or not this was an issue with the wkhtmltopdf binary that comes with homebrew.

[djhopper01]

I see this issue as well. which wkhtmltopdf shows /usr/local/bin/wkhtmltopdf which is a link to ../Cellar/wkhtmltopdf/0.11.0_rc1/bin/wkhtmltopdf. However, I see the 0.10 when I run wkhtmltopdf --version.

[inkstak]

Hi,

The problem comes from wkhtmltopdf. It has been reported at http://code.google.com/p/wkhtmltopdf/issues/detail?id=141. I also used OSX 10.7.4 and wkhtmltopdf 0.11.rc1.

By waiting a solution, I moved back to 0.9.9 and it works.

[peteroome]

Currently running OSX 10.7.4 and wkhtmltopdf 0.9.9 and this isn't working for me. wkhtmltopdf bin icon appears in my dock but clicking it or exiting it does nothing and Firefox just outputs a "Connection was reset" error after approx 10 seconds.

[dsnipe]

Same problem. OSX 10.7.4, wkhtmltopdf 0.10.0 rc2 (installed by homebrew).

[peteroome]

I got this working in the end. Rolling back to version 0.9.9 fixed the problem for me.

I also had to be careful as i was using Unicorn with a process timeout of 30s. I had some PDF's (before optimisation) which were taking longer than 30s to generate so i was getting timeout errors, as you'd expect.

If you're not sure about how to rollback to an older package version using Homebrew, i did a writeup here: Homebrew and installing old package versions.

[giedriusr]

Same problem here. Tried so many different options. Such a simple task, so many problems with dependencies and native extensions..

[Dreyfuzz]

I'm on OS 10.6.8, same issue. Solved by rolling back wkhtmltopdf to 0.9.9. Now the wkhtmltopdf shell just pops up and disappears, leaving a beautiful pdf in the browser. Here's full steps, for newbs:

Step 1: uninstall wkhtmltopdf $ brew uninstall wkhtmltopdf Uninstalling /usr/local/Cellar/wkhtmltopdf/0.11.0_rc1...

Step 2: find version 0.9.9 $ brew versions wkhtmltopdf 0.11.0_rc1 git checkout aa80fbc /usr/local/Library/Formula/wkhtmltopdf.rb 0.9.9 git checkout 6e2d550 /usr/local/Library/Formula/wkhtmltopdf.rb

Step 3: Copy and paste the git checkout command (everything from git over to the right): $ git checkout 6e2d550 /usr/local/Library/Formula/wkhtmltopdf.rb

Step 4: reinstall $ brew install wkhtmltopdf

The last output line should say something like /usr/local/Cellar/wkhtmltopdf/0.9.9: 6 files, 424K, built in 15 seconds

[aledalgrande]

Before step 3 you have to cd to /usr/local/Library/Formula/ otherwise you will get a fatal: '/usr/local/Library/Formula/wkhtmltopdf.rb' is outside repository error.

[dsci]

Same problem here: OSX 10.7.5 and newest wkhtmltopdf from homebrew. The solution to roll back to 0.9.9 works fine for me.

[scarver2]

Thanks for the dialog. I have documented the correct installation of 0.9.9 here: http://stackoverflow.com/questions/12517640/why-does-pdfkit-wkhtmltopdf-hang-but-renders-pdf-as-expected-when-rails-app-is-k/14043085#14043085

[gamov]

I've just migrated to 10.8.3 and now, wkhtmltopdf is showing up in the Dock when converting PDF... is there a way to stop this Dock 'appearance'?

[Dreyfuzz]

If it goes away once the PDF is rendered, don't worry about it. It's just showing that the script is running on your machine. It won't happen in production.

[DonGiulio]

installing 0.9.9 worked for me,

is it possible that it's been two major releases since the last working version?

is this issue happening only to MAC users?

[unixmonkey]

As far as I've ever heard, this only affects OSX builds of wkhtmtopdf binaries. Most production systems run Linux or Windows, that do not suffer this strange behavior, and it is one of the reasons I have recommended in the past for people to stick with 0.9.6. I plan to investigate more this weekend, as that is quite old now, and a few major releases behind.

[dbourguignon]

For information, this seems to be fixed with last binary package from here http://wkhtmltopdf.org/downloads.html I just installed 0.12.1 (carbon edition) and it worked

[dbourguignon]

Well not so bright: I still have some PDF not working. Apparently it hangs for larger files like this : https://gist.github.com/dbourguignon/59668a75c739ced50eb4 with big CSS data But using command line on this file work well.

[JuanitoFatas]

wkhtmltopdf 0.12.2.1 with wicked_pdf 0.9.9 or 0.11.0 on OS X 10.10.1 got same problem.

See my next comment.

[JuanitoFatas]

For people who use Puma. You need at least 2 process worker. With only 1 worker it will freeze. Change to 2 workers worked for me. The number of process workers can be set in config/puma.rb.

[grantgeorge]

@JuanitoFatas I hang when using 'rails s' to serve my app on Mac. Any idea if this is related / is there a way to increase # of workers using the default rails s?

[renatofb]

Hi People I was struggling to make it work but I was having constant freezes, all as described in previous messages here. I am Cent OS 6.6 64bits, with latest binary 0.12.2.1 downloaded from http://wkhtmltopdf.org/downloads.html . I am new to this project, but when I heard lots of complain I thought that it would not be possible to use it.

Luckily after reading these posts and thanks to @beerlington saying that he had problem after installing the 0.11.0_rc1 I installed a previous version 0.10.0_rc2 which is now working fine with no freezes. I also noticed that even charts generated by flot improved quality with same settings I was using before.

It seems that problem occurred with version 0.11.0_rc1 and it is common to every platform.

Despite this, after all is working now smoothly, I can say it is a great project.

[TheFox]

It freezes with version 0.10.0 rc2.

[nagrgk]

just comment below line if you face issues again (from application.rb).

config.middleware.use WickedPdf::Middleware

[svoop]

The wkhtmltopdf (0.12.4 on MacOS) binary hangs if the following conditions are met:

• wicked_pdf is used as middleware in a Rails app.
• There are external resources (JS, CSS, images etc) used by the view.
• The server is bound to localhost or 127.0.0.1

Funny enough, when I run the dumped wkhtmltopdf command in a separate terminal, the PDF is generated without any problem.

Here's a workaround: External resources must not be fetched from localhost. When I serve local development through a remote proxy which tunnels the request back to my locally running server, everything works just fine. (I haven't tried localtunnel, you might want to have a go.)

So the question seems to be: Why can wkhtmltopdf fetch resources from localhost when run in a full interactive shell, but fails to do so when run by wicked_pdf as middleware?

[unixmonkey]

@svoop The middleware is a lot dumber bout how it fetches resources. It catches the HTML as rendered before it gets served, and swaps out relative URLs with absolute ones here.

Otherwise, you'd have to customize every page to use wicked_pdf_* helpers, which is very un-middleware-like, in my opinion.

[chorstikus]

Works for me with 127.0.0.1:3000 instead of localhost:3000

[bbugh]

@chorstikus you saved the day. This worked for me:

config.action_controller.asset_host = 'http://127.0.0.1:3000'

Now all of our asset_url paths are working correctly and automatically with wickedpdf, without having to use any wicked helpers.

---

Side note: this worked perfectly running the puma command (because puma by default binds to 0.0.0.0) but using rails s we had to override the default Rails setting to respond to 127.0.0.1 as well, like so:

# add to the bottom of config/boot.rb, RAILS 5 ONLY
require 'rails/commands/server'

module DefaultOptions
  def default_options
    super.merge!(Host: '0.0.0.0')
  end
end

Rails::Server.prepend(DefaultOptions)

For other versions of Rails, see this Stack Overflow answer: https://stackoverflow.com/a/29946020/1742070

[pokrovskyy]

For those using Puma and wkhtmltopdf - @JuanitoFatas made a good point with 2+ workers. Puma uses round-robin with some load-balancing algorithm to distribute incoming requests. For some reason (I believe it can be perfectly justified) Puma may send some incoming requests to the same busy worker involved in PDF generation. If you have a bunch of assets and just a few or less workers - there's a good chance that some asset request will be sent to the PDF worker locking the whole thing up. I believe this may be somehow tuned up, but a quick solution is to just spin up more workers temporarily while working on PDF-related stuff, eg.

puma -w 16 -p 3000

I believe similar concept may relate to other app servers. Hope this helps!