OpenJDK + Chromium

done
chrome
image-rendering
normal_priority
reply

(Michael Iben) #1

We have read that Looker now supports OpenJDK. In the process of upgrading our installation to use the Looker API to download Looker jar files, we tried switching from Oracle JDK to OpenJDK. Looker seemed to run just fine except when trying to render a look as a PNG under Chromium. The render logs a success but then the Looker java process stops. The process stops with no errors, exit (0). We can run the PhantomJS render under OpenJDK fine.

OracleJDK+PhantomJS= OK
OracleJDK+Chromuim=OK
OpenJDK+PhantomJS=OK
OpenJDK+Chromium=Bad

Has anyone else experienced this issue?

Running Ubuntu 18.04, Looker 6.6, (OracleJDK 8u202, OpenJDK 8u181)

Thanks!


(Izzy) #2

That’s the officially recommended version of OpenJDK, so all seems well from that perspective. I’m going to loop in Support on this one to see if it’s a known issue or something we haven’t yet seen.

We’ll definitely take a look at it, glad you’re running alright on OracleJDK in the meantime.


(Michael Iben) #3

I don’t think my original post is the problem. I was able to get things to work on ubuntu, just not on debian stretch. When trying to execute the command looker executes when running chromium on debian, there is an error. I am investigating why that is. If I remove the --remote-debugging-port=9222 attribute, the command works fine. I don’t think OpenJDK is the issue here.

chromium --show-component-extension-options --ignore-gpu-blacklist --no-default-browser-check --disable-pings --media-router=0 --enable-remote-extensions --headless --disable-gpu --hide-scrollbars --remote-debugging-port=9222 --disable-logging --disable-translate --force-device-scale-factor=1 --disable-extensions --disable-background-networking --safebrowsing-disable-auto-update --disable-sync --metrics-recording-only --disable-default-apps --mute-audio --no-first-run --no-default-browser-check --no-startup-window --disable-plugin-power-saver --disable-popup-blocking

[0306/165333.197082:INFO:cpu_info.cc(46)] Available number of cores: 2
[0306/165333.197488:VERBOSE1:zygote_main_linux.cc(217)] ZygoteMain: initializing 0 fork delegates
[0306/165333.215577:VERBOSE1:pulse_util.cc(203)] Failed to connect to the context. Error: Connection refused
[0306/165333.217936:VERBOSE1:webrtc_internals.cc(123)] Could not get the download directory.
Received signal 11 SEGV_MAPERR 000000000080
#0 0x55dac5264791 <unknown>
#1 0x55dac5264bfb <unknown>
#2 0x55dac526525e <unknown>
#3 0x7f29020300e0 <unknown>
#4 0x55dac364c314 <unknown>
#5 0x55dac36571b7 <unknown>
#6 0x55dac8d3f5e6 <unknown>
#7 0x55dac8d3f69a <unknown>
#8 0x55dac35e8fd3 <unknown>
#9 0x55dac3a62c32 <unknown>
#10 0x55dac35eb089 <unknown>
#11 0x55dac35ec039 <unknown>
#12 0x55dac98118b5 <unknown>
#13 0x55dac4d0f2d7 <unknown>
#14 0x55dac4d0f581 <unknown>
#15 0x55dac4d0f930 <unknown>
#16 0x55dac4d1abfa <unknown>
#17 0x55dac4d0d745 <unknown>
#18 0x55dac8d45363 <unknown>
#19 0x55dac8d45554 <unknown>
#20 0x55dac4d17dc9 <unknown>
#21 0x55dac29b5d6d ChromeMain
#22 0x7f28f445a2e1 __libc_start_main
#23 0x55dac29b5b8a _start
  r8: 0000000000000001  r9: 0000000000000040 r10: 00007f28c57fa9d0 r11: 0000000000000202
  r12: 00007fffb103ea10 r13: 000055daccdfa3e0 r14: 00007fffb103ea60 r15: 000055daccdf46d0
  di: 00007fffb103ea10  si: 000055dac9dfc8f0  bp: 00007fffb103eab0  bx: 000055daccdf47a0
  dx: 000055dac364c314  ax: 00007fffb103ea10  cx: 0000000000000319  sp: 00007fffb103e9b0
  ip: 000055dac364c314 efl: 0000000000010206 cgf: 002b000000000033 erf: 0000000000000004
  trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000080
[end of stack trace]
Calling _exit(1). Core file will not be generated.

(Izzy) #4

Oh interesting. I punted to google with that error and found this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922794. Looks like it’s a Debian bug.

Debian isn’t explicitly named in our list of supported versions, but we do strive to support all major distro’s. That said— I don’t think we’ll leap at the chance to change our architecture just to be compatible with a (hopefully) temporary bug with Debian, but I will ask an engineer if they see a super easy way to work around this. :slight_smile:

Keep us posted if you find anything!


(Michael Iben) #5

Solved. Debian Stretch, OpenJDK, Chromium

Installed chromium on debian using:
apt-get install chromium

This is what kept having issues. I was able to identify a previous version of Chromium using:
apt-cache madison chromium

chromium | 72.0.3626.96-1~deb9u2 | http://security.debian.org/debian-security stretch/updates/main amd64 Packages
chromium | 70.0.3538.110-1~deb9u1 | http://deb.debian.org/debian stretch/main amd64 Packages

I installed the older version 70.0.3538.110-1~deb9u using:
apt-get install chromium=70.0.3538.110-1~deb9u1

This version worked rendering a look png. The version 72.0.3626.96-1~deb9u2 gives a stack trace.


(Izzy) #6

:metal: Awesome!

I did some more sleuthing and we actually have some records of this happening— Rolling back the version works fine, but so does installing Chrome instead of chromium (steps below).

  • Run wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb to download the .deb file for Chrome from Google.
  • Run sudo apt install ./google-chrome-stable_current_amd64.deb to install the package
  • Uninstall chromium by running sudo apt remove chromium
  • Run sudo ln -s /usr/bin/google-chrome-stable /usr/bin/chromium to create a symlink from the place that Looker will look for the chromium executable to the google-chrome-stable executable.

But it sounds like using the older version also works fine, glad you’re all set! Thanks for sharing the fix.


(Michael Iben) #7

Confirmed Chrome Browser works fine as well. I prefer that method as the installation is simple. Should add this installation option to the Debian renderer installation page https://help.looker.com/hc/en-us/articles/360016994793

One of the items in the Looker Installation documentation https://docs.looker.com/setup-and-management/on-prem-install/installation is:
Download the latest startup script at [this GitHub repo](https://github.com/looker/customer-scripts/tree/master/startup_scripts)

That script doesn’t take into account OpenJDK in the version check. The regex only checks for the text ‘java version’. I just manually fixed it for now.
java -version
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

Everything is running!


(Izzy) #8

I’ve passed those helpful pieces of feedback over to the content team, thanks much and glad you’re running smoothly.