We've got a Java application that generates word documents using a 3rd party (Asposee but I don't think it matters here). The app is built from a simple Docker file:
FROM openjdk:10-jdk-slim
COPY target/*.jar /opt/
CMD $JAVA_HOME/bin/java $JAVA_OPTS -jar /opt/*.jar
When we build the application locally (mvn package then docker build) and run the application inside k8s it works well.
However, when we build the image in our CI/CD pipeline with Jenkins we get a runtime exception when running through a specific process which apparently requires additional fonts:
Caused by: java.lang.NullPointerException: null
at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1288)
at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:225)
at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:107)
at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:765)
at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:440)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.desktop/sun.font.SunFontManager.<init>(SunFontManager.java:385)
at java.desktop/sun.awt.FcFontManager.<init>(FcFontManager.java:35)
at java.desktop/sun.awt.X11FontManager.<init>(X11FontManager.java:56)
In that case the project is buit in Jenkins, compiled by the docker image maven:3.5.4-jdk-10-slim.
I've checked both jar files (locally and from jenkins) and the class files are the same (as expected).
In both cases it's the same base image so I don't understand what could be the difference. Is something different in Docker when building locally vs inside another Docker container?
EDIT
We've looked into both docker images and found the following difference.
Since locally built image ls -l /usr/lib returns:
drwxr-xr-x 2 root root 4096 May 3 2017 X11
drwxr-xr-x 5 root root 4096 Apr 26 00:00 apt
drwxr-xr-x 2 root root 4096 May 26 08:31 binfmt.d
drwxr-xr-x 2 root root 4096 Jun 6 01:50 cgmanager
drwxr-xr-x 2 root root 4096 Jun 6 01:50 dbus-1.0
drwxr-xr-x 2 root root 4096 Jun 6 01:51 dconf
drwxr-xr-x 3 root root 4096 Jun 6 01:51 debug
drwxr-xr-x 3 root root 4096 Apr 20 10:08 dpkg
drwxr-xr-x 2 root root 4096 Jun 6 01:50 environment.d
drwxr-xr-x 3 root root 4096 Apr 25 04:56 gcc
drwxr-xr-x 2 root root 4096 Jun 6 01:51 glib-networking
drwxr-xr-x 2 root root 4096 Apr 26 00:00 init
drwxr-xr-x 1 root root 4096 Jun 6 01:51 jvm
drwxr-xr-x 3 root root 4096 Jun 6 01:50 kernel
lrwxrwxrwx 1 root root 20 Mar 4 09:49 libnih-dbus.so.1 -> libnih-dbus.so.1.0.0
-rw-r--r-- 1 root root 34824 Mar 4 09:49 libnih-dbus.so.1.0.0
lrwxrwxrwx 1 root root 15 Mar 4 09:49 libnih.so.1 -> libnih.so.1.0.0
-rw-r--r-- 1 root root 92184 Mar 4 09:49 libnih.so.1.0.0
drwxr-xr-x 3 root root 4096 Mar 29 19:47 locale
drwxr-xr-x 3 root root 4096 Jun 6 01:50 lsb
drwxr-xr-x 1 root root 4096 Jul 21 2017 mime
drwxr-xr-x 2 root root 4096 Jun 6 01:50 modprobe.d
drwxr-xr-x 2 root root 4096 May 26 08:31 modules-load.d
-rw-r--r-- 1 root root 198 Jan 13 23:36 os-release
drwxr-xr-x 3 root root 4096 Jun 6 01:51 ssl
drwxr-xr-x 1 root root 4096 Jun 6 01:50 systemd
drwxr-xr-x 2 root root 4096 Jun 6 01:50 sysusers.d
drwxr-xr-x 2 root root 4096 Jul 21 2017 tar
drwxr-xr-x 15 root root 4096 Feb 11 20:06 terminfo
drwxr-xr-x 1 root root 4096 Jun 6 01:50 tmpfiles.d
drwxr-xr-x 1 root root 4096 Apr 26 00:00 udev
drwxr-xr-x 1 root root 16384 Jun 6 01:51 x86_64-linux-gnu
But inside Jenkins built image ls -l /usr/lib returns:
drwxr-xr-x 5 root root 4096 Jun 25 00:00 apt
drwxr-xr-x 3 root root 4096 Jul 3 01:00 debug
drwxr-xr-x 3 root root 4096 Apr 20 10:08 dpkg
drwxr-xr-x 3 root root 4096 Jun 17 03:36 gcc
drwxr-xr-x 2 root root 4096 Jun 25 00:00 init
drwxr-xr-x 1 root root 4096 Jul 3 01:00 jvm
drwxr-xr-x 1 root root 4096 Jul 12 11:00 locale
drwxr-xr-x 3 root root 4096 Jul 3 01:00 lsb
drwxr-xr-x 1 root root 4096 May 16 07:47 mime
-rw-r--r-- 1 root root 198 Jan 13 23:36 os-release
drwxr-xr-x 3 root root 4096 Jul 3 01:00 ssl
drwxr-xr-x 3 root root 4096 Apr 20 10:08 systemd
drwxr-xr-x 2 root root 4096 May 16 07:47 tar
drwxr-xr-x 15 root root 4096 May 21 08:54 terminfo
drwxr-xr-x 2 root root 4096 Jun 25 00:00 tmpfiles.d
drwxr-xr-x 3 root root 4096 Jun 25 00:00 udev
drwxr-xr-x 2 root root 4096 May 3 2017 X11
drwxr-xr-x 1 root root 4096 Jul 3 01:00 x86_64-linux-gnu
This is really puzzling as I thought Docker would always produce the same image from identical Dockerfiles
With openjdk:8u111-jdk-alpine, installing dejavu fix the problem:
For example:
Dockerfile:
FROM openjdk:8u111-jdk-alpine
# Needed to fix 'Fontconfig warning: ignoring C.UTF-8: not a valid language tag'
ENV LANG en_GB.UTF-8
# JRE fails to load fonts if there are no standard fonts in the image; DejaVu is a good choice,
# see https://github.com/docker-library/openjdk/issues/73#issuecomment-207816707
RUN apk add --update ttf-dejavu && rm -rf /var/cache/apk/*
VOLUME /tmp
COPY /target/*.jar app.jar
ENTRYPOINT ["java","-Xmx100m","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]
Just add the following in your Dockerfile
RUN apk add --no-cache fontconfig ttf-dejavu
Installing libfontconfig1 solved the problem for me (source):
RUN apt-get install -y libfontconfig1 && rm -rf /var/lib/apt/lists/*
I think we found the problem.
When running on Jenkins we use the docker:dind (Docker inside docker) Docker image to provide the docker command in the build. This image is based on Alpine linux. When running docker info we get the following:
On Mac:
Kernel Version: 4.9.87-linuxkit-aufs
Operating System: Docker for Mac
On Jenkins:
Kernel Version: 4.4.115-k8s
Operating System: Alpine Linux v3.7 (containerized)
Alpine linux must be missing those fonts. We fixed the problem by manually installing them in the Dockerfile:
RUN apt-get update \
&& apt-get install --assume-yes apt-utils \
&& apt-get install --assume-yes software-properties-common \
&& apt-get install --assume-yes dbus \
&& apt-get install --assume-yes cgmanager \
&& apt-get install --assume-yes glib-networking \
&& apt-get install --assume-yes libnih-dbus-dev \
&& apt-get install --assume-yes dconf-cli \
&& apt-get install --assume-yes fontconfig
Not sure this is the minimum required libraries but those did the trick :D
If you trying to do in Java/Spring boot , adding following in Dockerfile worked for me in java 11.
# Font packages to be added for java 11
RUN apk update \
&& apk add fontconfig \
&& apk add ttf-dejavu
RUN ln -s /usr/lib/libfontconfig.so.1 /usr/lib/libfontconfig.so && \
ln -s /lib/libuuid.so.1 /usr/lib/libuuid.so.1 && \
ln -s /lib/libc.musl-x86_64.so.1 /usr/lib/libc.musl-x86_64.so.1
ENV LD_LIBRARY_PATH /usr/lib
If you are running it on local with Docker Desktop and using docker file to create the image.
Please make changes in Dockerfile from FROM openjdk:8-jdk-alpine to FROM adoptopenjdk/openjdk11:ubi
Problem NullPointerException with fonts occurs when you use openjdk docker image in alpine version for example :
adoptopenjdk/openjdk11:jre-11.0.11_9-alpine.
You need change image to full version: adoptopenjdk/openjdk11:jre-11.0.11_9
I also got the same issue while running below command and restart app server resolved this issue.
Yup install fontconfig
Related
I got only jre folder for below java version but not the jdk folder.
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b08-1.el7_9.x86_64
--------------------------------------------------------------------------------
[AU\bhrbr2#abcdefd08 ~]$ cd /usr/lib/jvm
[AU\bhrbr2#abcdefd08 jvm]$ ls -lrt
total 0
drwxr-xr-x 3 root root 16 Jan 27 17:04 java-1.8.0-openjdk-1.8.0.362.b08-1.el7_9.x86_64
lrwxrwxrwx 1 root root 51 Jan 27 17:04 jre-1.8.0-openjdk-1.8.0.362.b08-1.el7_9.x86_64 -> java-1.8.0-openjdk-1.8.0.362.b08-1.el7_9.x86_64/jre
lrwxrwxrwx 1 root root 29 Jan 27 17:04 jre-openjdk -> /etc/alternatives/jre_openjdk
lrwxrwxrwx 1 root root 27 Jan 27 17:04 jre-1.8.0 -> /etc/alternatives/jre_1.8.0
lrwxrwxrwx 1 root root 35 Jan 27 17:04 jre-1.8.0-openjdk -> /etc/alternatives/jre_1.8.0_openjdk
lrwxrwxrwx 1 root root 21 Jan 27 17:07 jre -> /etc/alternatives/jre
[AU\bhrbr2#abcdefd08 jvm]$ cd java-1.8.0-openjdk-1.8.0.362.b08-1.el7_9.x86_64
[AU\bhrbr2#abcdefd08 java-1.8.0-openjdk-1.8.0.362.b08-1.el7_9.x86_64]$ ls -lrt
total 0
drwxr-xr-x 4 root root 90 Jan 27 17:04 jre
--------------------------------------------------------------------------------
How can I get the JDK folder for this version?
I got the required jdk from OpenLogic site.
https://www.openlogic.com/openjdk-downloads?field_java_parent_version_target_id=416&field_operating_system_target_id=426&field_architecture_target_id=391&field_java_package_target_id=All
But I want to just install jdk alone using yum/rpm command line in RHEL for same version (as I already have the jre) under the same directory.
Thanks.
When I was running some test instances on multiple server I encountered a not enough space on some of the locations and as I inspected it was an issue with logger.
I use #Slf4j annotation to log.
Here is my configuration for logging:
# Logging
logging.level.root=INFO
logging.level.web=INFO
logging.logback.rollingpolicy.max-file-size=20MB
logging.file.name=logs/ims-app.log
logging.file.path=logs
logging.logback.rollingpolicy.max-history=7
Recent logs inside the docker:
/logs # ls -lah
total 7M
drwxr-xr-x 2 root root 4.0K Sep 22 17:40 .
drwxr-xr-x 1 root root 4.0K Sep 22 11:26 ..
-rw-r--r-- 1 root root 543.8K Sep 22 17:41 ims-app.log
-rw-r--r-- 1 root root 507.2K Sep 22 11:52 ims-app.log.2022-09-22.0.gz
-rw-r--r-- 1 root root 507.1K Sep 22 12:21 ims-app.log.2022-09-22.1.gz
-rw-r--r-- 1 root root 495.6K Sep 22 16:21 ims-app.log.2022-09-22.10.gz
-rw-r--r-- 1 root root 497.5K Sep 22 16:48 ims-app.log.2022-09-22.11.gz
-rw-r--r-- 1 root root 495.7K Sep 22 17:14 ims-app.log.2022-09-22.12.gz
-rw-r--r-- 1 root root 496.6K Sep 22 17:40 ims-app.log.2022-09-22.13.gz
-rw-r--r-- 1 root root 496.2K Sep 22 12:48 ims-app.log.2022-09-22.2.gz
-rw-r--r-- 1 root root 499.8K Sep 22 13:15 ims-app.log.2022-09-22.3.gz
-rw-r--r-- 1 root root 497.8K Sep 22 13:42 ims-app.log.2022-09-22.4.gz
-rw-r--r-- 1 root root 498.6K Sep 22 14:09 ims-app.log.2022-09-22.5.gz
-rw-r--r-- 1 root root 499.5K Sep 22 14:36 ims-app.log.2022-09-22.6.gz
-rw-r--r-- 1 root root 498.2K Sep 22 15:03 ims-app.log.2022-09-22.7.gz
-rw-r--r-- 1 root root 496.7K Sep 22 15:29 ims-app.log.2022-09-22.8.gz
-rw-r--r-- 1 root root 496.4K Sep 22 15:56 ims-app.log.2022-09-22.9.gz
After this issue I decided to move to a centralized logging with elk, but this issue will still continue on the java side. How do I limit how many log file for an instance. I still want to save recent logs as files, but in 30 days it exceeded 19GB (on the dev server) any suggestion on this?
You should not produce log files inside a running container. Just instruct log4j to write to standard output. This is a good practice.
If you need the files then map a volume and have the files saved in that folder. This way your container is not impacted and your only problem is the space on the host.
I did everythin' like in Spring documentation to deploy my app on AWS. But got an error:
deploy-demo.service: Failed at step EXEC spawning /opt/deploy-demo/deploy-demo.jar: Exec format error
Sep 07 21:22:10 ip-172-31-45-166 systemd[1]: deploy-demo.service: Main process exited, code=exited, status=203/EXEC
My deploy-demo.service file located in /etc/systemd/system/deploy-demo.service with settings:
[Unit]
Description=deploy-demo
After=syslog.target
[Service]
User=gitlab-runner
ExecStart=/opt/deploy-demo/deploy-demo.jar
SuccessExitStatus=143
[Install]
WantedBy=multi-user.target
deploy-demo.jar and deploy-demo.conf located in /opt/deploy-demo/
deploy-demo.conf file contains
RUN_ARGS="--spring.datasource.url=jdbc:postgresql://here_is_should_be_my_host:5432/helpfast --spring.datasource.username=postgres --spring.datasource.password=adminadmin"
All permissions seems to me correct:
drwxr-xr-x 2 gitlab-runner gitlab-runner 4096 Sep 7 21:21 ./
drwxr-xr-x 3 root root 4096 Sep 7 20:31 ../
-r-------- 1 gitlab-runner gitlab-runner 200 Sep 7 21:21 deploy-demo.conf
-r-x------ 1 gitlab-runner gitlab-runner 42645024 Sep 7 20:31 deploy-demo.jar*
Any ideas are highly appreciated!
Rackspace replaced an outdated certificate, ive followed their instructions using keytool to update the cacerts for java 6 with no success (keytool).
What did work was just replacing the cacerts file from java 6 with one from java 8.
Is this "OK" to do? i assume formats between the two are the same and they are simply updated between version.
Apologies in advance if this is a stupid question
I initially did the same thing, and then symlinked to the java 8 file. But my problem was that the java 6 installation on macOs High Sierra (10.13.x).
# store path to java 6 home
tmp $ j6Security=$(/usr/libexec/java_home -v '1.6*')/lib/security;
# show pre-update state
tmp $ ls -la "$j6Security"
total 16
drwxr-xr-x 10 root wheel 320 Jan 20 19:39 .
drwxr-xr-x 41 root wheel 1312 Jan 20 19:39 ..
-rw-r--r-- 1 root wheel 2469 Jul 14 2015 US_export_policy.jar
lrwxr-xr-x 1 root wheel 79 Jan 20 19:39 blacklist -> /System/Library/Java/Support/Deploy.bundle/Contents/Home/lib/security/blacklist
lrwxr-xr-x 1 root wheel 81 Jan 20 19:39 cacerts -> /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security/cacerts
-rw-r--r-- 1 root wheel 3443 Jul 14 2015 java.policy
-rw-r--r-- 1 root wheel 13458 Jul 14 2015 java.security
-rw-r--r-- 1 root wheel 2486 Jul 14 2015 local_policy.jar
-rw-r--r-- 1 root wheel 347 Jul 14 2015 sunpkcs11-macosx.cfg
lrwxr-xr-x 1 root wheel 87 Jan 20 19:39 trusted.libraries -> /System/Library/Java/Support/Deploy.bundle/Contents/Home/lib/security/trusted.libraries
# store path to current (i.e., switcher) home
tmp $ jXSecurity=/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security;
# replace (broken) j6 files with symlink to current files
tmp $ for file in blacklist cacerts trusted.libraries; do src="${jXSecurity}/${file}" tgt="${j6Security}/${file}"; test -f $tgt && sudo rm $tgt; sudo ln -s "$src" "$tgt"; done
# show post-update state
tmp $ ls -la "$j6Security"
total 16
drwxr-xr-x 10 root wheel 320 Jan 20 20:33 .
drwxr-xr-x 41 root wheel 1312 Jan 20 19:39 ..
-rw-r--r-- 1 root wheel 2469 Jul 14 2015 US_export_policy.jar
lrwxr-xr-x 1 root wheel 87 Jan 20 20:33 blacklist -> /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/blacklist
lrwxr-xr-x 1 root wheel 85 Jan 20 20:33 cacerts -> /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacerts
-rw-r--r-- 1 root wheel 3443 Jul 14 2015 java.policy
-rw-r--r-- 1 root wheel 13458 Jul 14 2015 java.security
-rw-r--r-- 1 root wheel 2486 Jul 14 2015 local_policy.jar
-rw-r--r-- 1 root wheel 347 Jul 14 2015 sunpkcs11-macosx.cfg
lrwxr-xr-x 1 root wheel 95 Jan 20 20:33 trusted.libraries -> /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/trusted.libraries
If I wanted to pin j8, I would replace jXSecurity=/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/trusted.libraries with j8Security=$(/usr/libexec/java_home -v '1.8*'). Both this and copying the files (that I've symlinked in this example) worked fine.
(In my case the installed symlinks (in the "pre-update" output) pointed to nonexistent files. My maven downloads were failing with "peer not authenticated". After applying these changes to my jdk6 installation everything began working again.)
I am using STS since a long time and the only feature annoys me is, it creates a new Pivotal tc Server instance in every workspace created and I never use Pivotal tc.
Can anyone tell me how to completely remove Pivotal tc Server from STS installation?
I have tried to update the artifacts.xml file, bundles.info (equinox) and bluntly deleting the features for Pivotal tc but I've never got clean result.
Once you unzipped the distribution it should have a folder with tc-server in it. Simply delete that entire folder and STS will no longer try and create a tc-server install in your workspace.
For example in my installation it looks like this:
$ ls -la sts-bundle/
total 20
drwxrwxr-x 5 kdvolder kdvolder 4096 Oct 12 05:47 .
drwxr-xr-x 23 kdvolder kdvolder 4096 Nov 6 14:43 ..
drwxr-xr-x 2 kdvolder kdvolder 4096 Oct 11 04:03 legal
drwxr-xr-x 11 kdvolder kdvolder 4096 Oct 13 07:56 pivotal-tc-server-developer-3.2.8.RELEASE
drwxr-xr-x 9 kdvolder kdvolder 4096 Nov 3 15:41 sts-3.9.1.RELEASE
So simply delete the folder pivotal-tc-server-developer-3.2.8.RELEASE.