Open margaretupshur opened 3 years ago
I've seen the same error appearing about a week ago on my existing deployments and I haven't really found out so far, what's causing it unfortunately :(. For some reason when I created a new app on Heroku and deployed, the error was not happening for that new app (incl. after pushes). I have a feeling that something going awry with old/cached docker images being pulled (but it's just a feeling not good knowledge):
Two things for you to maybe check:
git push
https://devcenter.heroku.com/articles/build-docker-images-heroku-yml) instead of building the docker image locally and then uploading it to Heroku (which is what heroku container:push
does: https://devcenter.heroku.com/articles/container-registry-and-runtime).Keycloak 12.0.0 (WildFly Core 13.0.3.Final)
-- this is a rather old version. Unless you modified the first line in the Dockerfile to specify that version, it seems the build process is for some reason not pulling the latest base image. You should currently be seing something like Keycloak 13.0.1 (WildFly Core 15.0.1.Final)
.When did you deploy the image the first time to the current heroku app? (I saw the issues around Jun 2 I think). I'd be also interested to hear if you see the same effect that deploying to a new heroku app makes the problem disappear.
Hello,
I have an almost identical error message as @margaretupshur discussed in her issue. I deployed this Keycloak instance to Heroku to work in tandem with my web application about 3 months ago but first noticed this error message in my Heroku logs on June 1,. Also, I noticed your comment regarding the line: Keycloak 12.0.0 (WildFly Core 13.0.3.Final)
. I am having a similar error message whereas mine says Keycloak 12.0.4 (WildFly Core 13.0.3.Final)
instead.
This seems to happen now on a fresh heroku button deploy as well.
We ran into this problem yesterday on multiple Heroku instances. We weren't able to determine why it suddenly started happening — it wasn't coincidental with a deploy or upgrade — so we suspect some change the underlying Heroku platform. (Although it's quite strange that some of you ran into it months before we did.)
The error message Keycloak produces is absolutely godawful, but the problem it's running into is that Java's user.home
property is suddenly coming up empty, originating from this line here:
We tried a number of approaches to fix the problem, and eventually settled on giving it an explicit value through JAVA_OPTS
like this:
JAVA_OPTS="$JAVA_OPTS -Duser.home=/opt/jboss"
The entrypoint script starts a number of ancillary Java processes besides the core Keycloak server itself, so just injecting a user.home
value to keycloak/bin/standalone.sh
is not enough because those other services will still be missing one. Exporting an explicit value for HOME
in the script didn't work either. This is why we settled on modifying JAVA_OPTS
, but a Java wizard might know of a better way.
Here's the full patch we applied to fix our installations:
diff --git docker-entrypoint.sh docker-entrypoint.sh
index 6450b56..16aa30b 100755
--- docker-entrypoint.sh
+++ docker-entrypoint.sh
@@ -1,5 +1,34 @@
#!/bin/bash
+#
+# IMPORTANT
+#
+# We manually override `user.home` here because we suddently have a
+# catastrophic problem where the Java runtime was no longer able to find a
+# value for `user.home`, which failed start up on Heroku. It's unclear as to
+# exactly why (it seems likely due to an underlying change on the Heroku
+# platform), but we're able to fix the problem by hard-injecting a value for
+# `user.home`.
+#
+# I tried a number of methods to fix this, but using `JAVA_OPTS` is the one
+# that ended up working. Java doesn't seem to respect `HOME` if we export it.
+# We can inject `-Duser.home=` to the program at the bottom of this file and it
+# fixes that one program, but the file also boots a cluster of ancillary
+# services from subscripts which then don't get a `user.home` value. Exporting
+# it to `JAVA_OPTS` lets the main program and all ancillary programs get it.
+#
+
+# This group of lines copied from `bin/standalone.conf` in Keycloak because
+# Keycloak won't set any of them if we override `JAVA_OPTS` at all.
+if [ "x$JBOSS_MODULES_SYSTEM_PKGS" = "x" ]; then
+ JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman"
+fi
+JAVA_OPTS="-Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true"
+JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true"
+
+# Here's the added line.
+export JAVA_OPTS="$JAVA_OPTS -Duser.home=/opt/jboss"
+
# Set database config from Heroku DATABASE_URL
if [ "$DATABASE_URL" != "" ]; then
echo "Found database configuration in DATABASE_URL=$DATABASE_URL"
Thanks I experimented the same issue since last Friday. @brandur proposal worked on my heroku keycloak instance.
Same issue here since last reboot. The fix from @brandur works. Thanks a lot!
When I clone this and then redeploy it via the container registry with the same config variables I am getting the following error. It's happening right after the change-database.sh script is run in the docker-entrypoint file. I have the same versions, same config and the button worked for me originally. I'm trying to do this because I want to add a custom theme to KC.
I'm using the
heroku container:push web
andheroku container:release web
commands.