Missing libnss3.so after updating openjdk:8-jdk-alpine image

[mohannadj]

Hello,

I have a docker file that builds openjdk:8-jdk-alpine based images. When updating the image internally (from the docker file) using apk update && apk upgrade , and running my (spring-boot) app, it throws java.io.IOException: Error loading shared library libnss3.so: No such file or directory. However; after removing the apk update && apk upgrade and building the image again, the app runs smoothly.

I have logged into my images in both cases, and made sure that the file wasn't there on the first case, and was there after removing apk update && apk upgrade . In the later case, it was located in /usr/lib/

Is this a bug, or can you please inform me of what I might be missing ?

[gato]

same here

[mike-treadway]

I'm basing my image on node:10-alpine, which is based on alpine:3.9. Neither my docker file nor the node:10-alpine are doing an apk update and I'm still having this problem.

It's unclear what the work around is at this point. I hope this gets fixed soon.

[gato]

so far i've have fixed the issue by doing

RUN apk add --no-cache nss

on my Dockerfile, that install the missing .so file, but i don't know why it was present before and not now

[danielgrant]

We've also just been hit with this. We execute an apk update && apk upgrade during each build of our image, and today we've started getting the following error during start up of our Tomcat application:

Caused by: java.io.FileNotFoundException: /usr/lib/libnss3.so
	at sun.security.pkcs11.Secmod.initialize(Secmod.java:193)
	at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:218)
	... 100 more

The root cause appears to be the PostgreSQL driver establishing an SSL connection to an RDS endpoint.

Here's the output from our apk upgrade:

13:17:57  (1/7) Upgrading libcrypto1.1 (1.1.1a-r1 -> 1.1.1b-r1)
13:17:57  (2/7) Upgrading libssl1.1 (1.1.1a-r1 -> 1.1.1b-r1)
13:17:57  (3/7) Upgrading openjdk8-jre-base (8.191.12-r0 -> 8.201.08-r0)
13:17:57  (4/7) Upgrading openjdk8-jre (8.191.12-r0 -> 8.201.08-r0)
13:17:57  (5/7) Purging nss (3.41-r0)
13:17:57  (6/7) Purging nspr (4.20-r0)
13:17:57  (7/7) Purging sqlite-libs (3.26.0-r3)

I'm not sure which of the upgraded packages is causing APK to purge nss, but following up with apk add --no-cache nss seems to bring it back.

Edit: should probably add that we're targeting openjdk:8-alpine, which is pulling sha256:d2e2716147d1f7fe73b1a9f72a9cff7a7aa92d32eb8de4fffbfddc596e004984.

[wglambert]

Looks like someone filed a bug upstream about this https://bugs.alpinelinux.org/issues/10126

[wglambert]

Probing the issue; I'm not so sure this is a bug with apk, perhaps something with openjdk8-jre-base dependencies

/ # apk --upgrade add openjdk8-jre-base
(1/4) Upgrading openjdk8-jre-base (8.191.12-r0 -> 8.201.08-r0)
(2/4) Purging nss (3.41-r0)
(3/4) Purging nspr (4.20-r0)
(4/4) Purging sqlite-libs (3.26.0-r3)
Executing java-common-0.1-r0.trigger
OK: 98 MiB in 51 packages

As a side note doing an apk upgrade goes against best practices for a couple reasons; it's reproducibility is temporally dependent, and it can yield unpredictable results without knowledge of what each package is updating or perhaps deprecating, which goes against the container's immutability.

[mohannadj]

Thank you guys for your feedback,

@wglambert , The problem is that we are updating apk; expecting that it wouldn't remove a system file that is required by whatever underlying system that might be using it, hence the bug. Didn't test it yet, but using the unzip tool also seemed to be affected by the upgrade.

I think the safest approach for now is to follow @gato 's recommendation, or find the last working openjdk image as what @danielgrant has mentioned. I remember pulling the latest (upgraded) working image around last Friday, maybe I'll start there.

Saying that, I don't think that this is a solution; but rather a workaround. Since this is my first time logging an issue here, do you think that we should close this one as it was already logged upstream ?

[wunderkind2k1]

so far i've have fixed the issue by doing

RUN apk add --no-cache nss

on my Dockerfile, that install the missing .so file, but i don't know why it was present before and not now

Just want to say having had the same problem this solution worked perfectly for us.

[danielgrant]

Taking a quick look between version 8.201.08-r0 of openjdk8-jre-base that is currently being installed by apk upgrade (https://pkgs.alpinelinux.org/package/v3.6/community/x86_64/openjdk8-jre-base) and version 8.181.13-r0 (https://pkgs.alpinelinux.org/package/v3.5/community/x86_64/openjdk8-jre-base), it looks like nss was dropped from the list of dependencies - you can see this by expanding out "Dependencies" on those pages.

I wonder if this was caused by increasing the version of IcedTea from 3.10.0 to 3.11.0, I'm looking specifically at this entry the changelog (https://mail.openjdk.java.net/pipermail/distro-pkg-dev/2019-March/041223.html):

• New features
  • PR3667: Use the internal copy of the SunEC library rather than statically linking against NSS

[arihasa4]

so far i've have fixed the issue by doing

RUN apk add --no-cache nss

on my Dockerfile, that install the missing .so file, but i don't know why it was present before and not now

Just want to say having had the same problem this solution worked perfectly for us.

You safe my day man. Thanks :)

[danielgrant]

FYI this has been resolved upstream: https://git.alpinelinux.org/aports/commit/?id=a0a5ffcea690a74b6f8c240d811be43542af60a6