wkhtmltopdf in init-rewrite branch (not rendering)

[l-arnold]

In Same Branch Report (PDF)

Wkhtmltopdf failed (error code: -11). Message:

Seems wkhtmltopdf should not be loaded at all except for wkhtmltox components.

Seems was in Main as a full package.

Not rendering any orders in "email or print" (base line test)

[DocCyblade]

Looks like this broke here Since I will not be merging this branch (rebase, cherry pick) I'll not use that commit.

[l-arnold]

sounds good.

[DocCyblade]

This should be fix with latest dev-rc1 branch

[DocCyblade]

@l-arnold - Need to track down at what point this worked? It's still broken. Did it work at v0.5?

[l-arnold]

It worked quite recently for sure. Let me look at the issue logs.

----- Original Message -----

From: "Ken Robinson" notifications@github.com To: "DocCyblade/tkl-odoo" tkl-odoo@noreply.github.com Cc: "L. Arnold" larnold@nomadic.net Sent: Wednesday, October 14, 2015 7:01:22 PM Subject: Re: [tkl-odoo] wkhtmltopdf in init-rewrite branch (not rendering) (#47)

@l-arnold - Need to track down at what point this worked? It's still broken. Did it work at v0.5?

— Reply to this email directly or view it on GitHub .

[l-arnold]

For sure it worked at Hotfix 4 https://github.com/DocCyblade/tkl-odoo/issues/13

Will look at 5 next

[l-arnold]

I'm not clear that we actually did a Beta 5.

[l-arnold]

I see your note: fixed 4.1 for wkhtmltox https://github.com/DocCyblade/tkl-odoo/issues/9

[l-arnold]

When I was looking at the build I did not understand why you were pulling th

wkhtmltopdf package in. Should do the manual pull for wkhtmltox plus a few dependencies.

[DocCyblade]

I just did a build for v0.5-beta

Installing now

[DocCyblade]

Beta 5 works so lets look at the changes since then (a lot) https://github.com/DocCyblade/tkl-odoo/compare/v0.5-beta...DocCyblade:dev-rc1

[l-arnold]

Basically was just a few settings. I need to get to a computer.

[l-arnold]

I see this fix saying "Fixes wkhtmltox issue" c4b22d8a68f1f31edaa3e69091991f5b381962e4 in conf.d/main but need to also look into

plan/main Line 38 should be removed wkhtmltopdf /* Command line utilities to convert html to pdf or image using WebKit */

the full package does not work and that is what is failing.

[DocCyblade]

Code at tag level v0.5-beta works. So any code after that we need to look at. That commit is before

I suspect it's in the config file

[DocCyblade]

I have installed a v0.5 ISO on VM, printing works fine

I have installed all the add ons to plan, reports still work

[DocCyblade]

@l-arnold

Found IT!

in /etc/odoo/openerp-server.conf workers = 2

For whatever reason in multi process mode we are getting this error. I change this back to 0 and it works. Looking into it now

[l-arnold]

But dev-rc1 does not worIk? I am seeing plan/main having wkhtmltopdf. I would remove it and see if it builds. I know when I first built wkhtmltox I had to remove wkhtmltopdf package. It will install but then will give the error, or at least one like this.

You know though, this actually could be a Memory Issue. I ran into that on my branch when I started using Workers = 2
Let me look for that.

[JedMeister]

I may have missed something somewhere so please excuse me if I bring outdated and/or irrelevant info! :smile:

IIRC the workers should relate to the number of cpu cores. Perhaps this is an issue if you set workers=2 when you only have 1 cpu core (e.g. in a VM)?

As a future feature; perhaps it could check how many cores it has and dynamically set the workers? And also perhaps check for RAM? Perhaps at first boot?

[l-arnold]

Thought I posted the "memory requirements" to get "workers = 2" to work. (This was in reference to running JobRunner with workers = 2 for the Magento Connector

The bottom of this issue outlines my fix: https://github.com/l-arnold/tkl-nomadic-odoo/issues/37

Specifically: openerp-server.conf needs memory limits updates to run this part of the system:

Moved the VM to 2 GB Ram (was running at 1gb and could run at 512mb)

Gave Odoo on openerp-server.conf

workers = 2 (was workers = 1) limit_memory_hard = 1730150400

was 805306368

limit_memory_soft = 943718400 was 671088640

[l-arnold]

Workers = 2 I believe Ken Implemented for gevent to get the live chat to work... there was also with this "pycogreen" package.

[l-arnold]

Yes, changing to those (quite high) memory limits allowed the Sales Order to Render. Alternatively, changing Workers to 0 should do the same.

This is with the same test from init-rewrite where it was not rendering earlier. (only changed the two lines in openerp-server-conf)

Rendered order below.

[DocCyblade]

Beat me to it

It's a resource issue with the workers. Should find out best numbers. We don't want them too high or could crash.

[l-arnold]

Why don't we make workers = 0. And document howb o go big as I was attempting. In my issue link above ?

[l-arnold]

Why don't we make workers = 0. Then document how to go big as I was attempting In my issue link above ?

[DocCyblade]

limit_memory_hard = 1610612736 is the magic number

workers = 2 is needed for the chat module with out it it does not work.

[DocCyblade]

Made a quick change to some files doing a full build now to quickly test it. If it works I'll push my changes up. If this works that should cover all the bugs so far

[l-arnold]

Where did you get 1610612736 from. It was hard enough getting 1730150400.

What about "Soft".

also, the CHAT Mode, in My Opinion is Not CRITICAL. It may be built in however. I have a module that disables it. It is basically setup to connect you to Odoo and get convinced to pay for support (IMHO).

The Module I believe is called "DeBranding". In OCA.

[DocCyblade]

I got the number by converting 1.5GB to bytes

It seems the only number that mattered was the hard limit.

Also not talking about the Odoo one, I am talking about im_livechat where you can host live chat your self.

[DocCyblade]

BTW, dev-rc1 code built fine and was able to print ok as well.

Just an FYI my VM is 512MB and one CPU

[DocCyblade]

@l-arnold - If you can do one last round of testing on current dev-rc1 I think we should be done?

[l-arnold]

Ok. New pull and make etc next.

[DocCyblade]

@l-arnold - Heading to bed, I'll be backup in the AM. If everything looks good. Close this issue. If it's closed I'll go ahead and mark for RC1 in the AM

[JedMeister]

Chiming (again) where perhaps I have missed something... But does this mean that it essentially would like 1.5GB (and will probably splill into swap if it doesn't have enough RAM) but will cope with less? Perhaps the "soft" limit should be set at 512? IDK just guessing...

I ask because it will be useful to know when we add this to the library. When we create the VM builds we can set default RAM. For most of the appliances it's currently 256MB; some are 384MB and the rest are 512MB (FWIW I am inclined to bump them all up x2 for v14.0 - i.e. 512, 768 & 1024 respectively - but we'll see what Alon says). They all default to 1CPU...

[l-arnold]

I have been running my test builds with 512mb and 2 Processors.

The Hard Limit allowed rendering to work so it seems they don't have to line up precisely.

That said, for Production I use 1 GB with Workers = 0 and (thinking as you are) I moved my ram to 2 gb when I increased the Memory Hard Limit and set Workers = 2. I am not clear however that this is critical. We should bounce on it a little bit.

I do think we should document how to reduce the Workers and the Limits personally.

My tests have not run into issues other than if the "hard limit" not being high enough to render. As Noted it did render even though I did not increase the actual ram by simply changing the numbers in the config file

[l-arnold]

dev-rc1 Renders Changed Passwords Generated Databases Dropped Databases No Crashes that I can see.

I am going to Close this for now.

[DocCyblade]

Regarding the limit_memory_hard option and why it seems to need at least 1.3G see https://github.com/DocCyblade/tkl-odoo/issues/62#issuecomment-148968899