Anyone here having issues with Apple silicon chips...
# cfml-general
j
Anyone here having issues with Apple silicon chips running Commandbox containers? More specifically, I have an M3 chip trying to run the latest Lucee5 Commandbox container but get
A fatal error has been detected by the Java Runtime Environment: SIGSEGV (0xb) at pc=0x00007ffffe614e29, pid=579, tid=583 JRE version: OpenJDK Runtime Environment Temurin-11.0.23+9 (11.0.23+9) (build 11.0.23+9)
(FWIW I have similar issues with Lucee's container too)
r
Might be worth cross-posting in #box-products
👍 1
b
What container are you using and what Java version are you using (The one that comes in the container, or one CommandBox installs for you on the fly)?
I assume this boils down to the wrong Java installation
j
ortussolutions/commandbox:latest
is the container image I'm using. I'm not changing any Java settings so I'm not sure whether it's on the fly or not. I'll see if I can figure that out
b
The verbose start console output from CommandBox would tell you
👍 1
I'll loop in @jclausen to discuss the Java arch we have in the docker container
j
Appreciate that. Here's as far the logs go before crashing
Copy code
[INFO] 2024-05-24T18:54:51Z - Server Home Directory defined in server.json as: /var/www/wwwroot
[INFO] 2024-05-24T18:54:51Z - Server Home Directory set to: /var/www/wwwroot
[INFO] 2024-05-24T18:54:51Z - Generating server startup script
Picked up JAVA_TOOL_OPTIONS: -Djava.util.logging.config.file=/usr/local/lib/build/resources/text.logging.properties 
[INFO] 2024-05-24T18:54:57Z - #
# A fatal error has been detected by the Java Runtime Environment:
FWIW I did have a successful build yesterday. No updates to macOS (Sonoma v14.5) since then. Same commandbox image
I do happen to have a copy of the logs from a successful build and I see
[INFO] 2024-05-22T14:36:21-04:00 runwar.server -  - Java Home: /opt/java/openjdk
Also some version info
[INFO] 2024-05-22T14:36:21-04:00 runwar.server -  - Java Version: 11.0.23+9 (Eclipse Adoptium)
b
Not is not the logs we're looking for
Where is the output from the actual server start command?
Or is Commandbox itself not even starting?
You can test by just running bash in your container and then firing off
box info
to see if box will even run
j
Yeah currently commadbox isn't even running. All calls to it fail with that same error
Again, these logs are from 2 days ago when it was working, but here's the full output before it randomly broke today:
Copy code
[INFO] 2024-05-22T18:36:21Z -  √ | Starting Server
   |------------------------------
   | Looking for server JSON file by convention: /app//server.json
   | webroot defaulted to location of server's JSON file: /app/
   | Site name - app
   | Webroot - /app/
   | Site config file - /app//server.json
   | WAR/zip archive already installed.
   | Start script for shell [bash] generated at: /app/server-start.sh
   | Server start command: 
   |     /opt/java/openjdk/bin/java 
   |     -cp /usr/local/lib/CommandBox/lib/runwar-5.0.0.jar runwar.Start /
   | var/www/wwwroot//serverInfo.jso
   | Dry run specified, exiting without starting server.
   |------------------------------
   | √ | Overriding server.json values from env vars
   |   |----------------------------------------------------------
   |   | Overridding [APP.SERVERHOMEDIRECTORY] with OS environment variable [B
   |   | OX_SERVER_APP_SERVERHOMEDIRECTORY
   |   | Overridding [CFCONFIGFILE] with OS environment variable [BOX_SERVER_C
   |   | FCONFIGFILE
   |   |----------------------------------------------------------
   | √ | Setting site [app] Profile to [production]
   |   |---------------------------------------------------------
   |   | Profile set from secure by default
   |   | Block CF Admin external
   |   | Block Sensitive Paths enabled
   |   | Block Flash Remoting enabled
   |   | Directory Browsing disabled
   |   | File Caching enabled
   |   |---------------------------------------------------------
   | √ | Loading CFConfig into server
   |   |-------------------------------------------
   |   | Found CFConfig JSON in "CFConfigFile" server.json key.
   |   | Importing luceeserver config from [/var/www/.CFConfig.json]
   |   | Config transferred from /var/www/.CFConfig.json!
   |   |-------------------------------------------
[INFO] 2024-05-22T18:36:21Z - Starting server using generated script: /usr/local/bin/startup.sh
NOTE: Picked up JDK_JAVA_OPTIONS:  --add-opens=java.base/sun.nio.ch=ALL-UNNAMED --add-opens=java.base/sun.nio.cs=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.annotation=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.base/java.lang.module=ALL-UNNAMED --add-opens=java.base/java.lang.ref=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED --add-opens=java.base/java.math=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/java.net.spi=ALL-UNNAMED --add-opens=java.base/java.nio=ALL-UNNAMED --add-opens=java.base/java.nio.channels=ALL-UNNAMED --add-opens=java.base/java.nio.channels.spi=ALL-UNNAMED --add-opens=java.base/java.nio.charset=ALL-UNNAMED --add-opens=java.base/java.nio.charset.spi=ALL-UNNAMED --add-opens=java.base/java.nio.file=ALL-UNNAMED --add-opens=java.base/java.nio.file.attribute=ALL-UNNAMED --add-opens=java.base/java.nio.file.spi=ALL-UNNAMED --add-opens=java.base/java.security=ALL-UNNAMED --add-opens=java.base/java.security.cert=ALL-UNNAMED --add-opens=java.base/java.security.interfaces=ALL-UNNAMED --add-opens=java.base/java.security.spec=ALL-UNNAMED --add-opens=java.base/java.text=ALL-UNNAMED --add-opens=java.base/java.text.spi=ALL-UNNAMED --add-opens=java.base/java.time=ALL-UNNAMED --add-opens=java.base/java.time.chrono=ALL-UNNAMED --add-opens=java.base/java.time.format=ALL-UNNAMED --add-opens=java.base/java.time.temporal=ALL-UNNAMED --add-opens=java.base/java.time.zone=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED --add-opens=java.base/java.util.concurrent.locks=ALL-UNNAMED --add-opens=java.base/java.util.function=ALL-UNNAMED --add-opens=java.base/java.util.jar=ALL-UNNAMED --add-opens=java.base/java.util.regex=ALL-UNNAMED --add-opens=java.base/java.util.spi=ALL-UNNAMED --add-opens=java.base/java.util.stream=ALL-UNNAMED --add-opens=java.base/java.util.zip=ALL-UNNAMED --add-opens=java.base/javax.crypto=ALL-UNNAMED --add-opens=java.base/javax.crypto.interfaces=ALL-UNNAMED --add-opens=java.base/javax.crypto.spec=ALL-UNNAMED --add-opens=java.base/javax.net=ALL-UNNAMED --add-opens=java.base/javax.net.ssl=ALL-UNNAMED --add-opens=java.base/javax.security.auth=ALL-UNNAMED --add-opens=java.base/javax.security.auth.callback=ALL-UNNAMED --add-opens=java.base/javax.security.auth.login=ALL-UNNAMED --add-opens=java.base/javax.security.auth.spi=ALL-UNNAMED --add-opens=java.base/javax.security.auth.x500=ALL-UNNAMED --add-opens=java.base/javax.security.cert=ALL-UNNAMED --add-opens=java.base/sun.net.www.protocol.https=ALL-UNNAMED --add-opens=java.desktop/com.sun.java.swing.plaf.motif=ALL-UNNAMED --add-opens=java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED --add-opens=java.desktop/javax.swing.plaf.nimbus=ALL-UNNAMED --add-opens=java.desktop/sun.java2d=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED --add-opens=java.base/sun.security.rsa=ALL-UNNAMED --add-opens=java.base/sun.security.pkcs=ALL-UNNAMED --add-opens=java.base/sun.security.x509=ALL-UNNAMED --add-opens=java.base/sun.security.util=ALL-UNNAMED --add-opens=java.base/sun.util.cldr=ALL-UNNAMED --add-opens=java.base/sun.util=ALL-UNNAMED --add-opens=java.base/sun.util.locale.provider=ALL-UNNAMED --add-opens=java.management/sun.management=ALL-UNNAMED  --add-exports=java.desktop/sun.java2d=ALL-UNNAMED --add-exports=java.base/sun.util=ALL-UNNAMED
Picked up JAVA_TOOL_OPTIONS: -Djava.util.logging.config.file=/usr/local/lib/build/resources/text.logging.properties 
WARNING: package com.sun.java.swing.plaf.windows not in java.desktop
[INFO] 2024-05-22T14:36:21-04:00 runwar.server - ******************************************************************************
[INFO] 2024-05-22T14:36:21-04:00 runwar.server - Starting Runwar
[INFO] 2024-05-22T14:36:21-04:00 runwar.server -   - Runwar Version: 5.0.0
[INFO] 2024-05-22T14:36:21-04:00 runwar.server -   - Java Version: 11.0.23+9 (Eclipse Adoptium)
[INFO] 2024-05-22T14:36:21-04:00 runwar.server -   - Java Home: /opt/java/openjdk
[INFO] 2024-05-22T14:36:21-04:00 runwar.server - ******************************************************************************
[INFO] 2024-05-22T14:36:21-04:00 runwar.server - Listeners:
[INFO] 2024-05-22T14:36:21-04:00 runwar.server -   - Binding HTTP on 0.0.0.0:8888
[INFO] 2024-05-22T14:36:21-04:00 runwar.server - ******************************************************************************
[INFO] 2024-05-22T14:36:21-04:00 runwar.server - Configuring Servlet
[INFO] 2024-05-22T14:36:21-04:00 runwar.server -   Found WEB-INF: '/var/www/wwwroot/WEB-INF'
[INFO] 2024-05-22T14:36:21-04:00 runwar.server - ******************************************************************************
[INFO] 2024-05-22T14:36:21-04:00 runwar.server - Creating deployment [default]
[INFO] 2024-05-22T14:36:21-04:00 runwar.server -     Web Root: /app
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by lucee.commons.lang.ClassUtil (jar:/var/www/wwwroot/WEB-INF/lucee-server/patches/5.4.4.38.lco) to constructor com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl()
WARNING: Please consider reporting this to the maintainers of lucee.commons.lang.ClassUtil
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
[INFO] 2024-05-22T14:36:22-04:00 runwar.server - ******************************************************************************
[INFO] 2024-05-22T14:36:22-04:00 runwar.server - Starting 'stop' listener thread - Host: 127.0.0.1 - Socket: 40849
[INFO] 2024-05-22T14:36:22-04:00 runwar.server - Server is up - stop-port:40849 PID:7 version 5.0.0
b
Well, I'm sure it wasn't "random". Just because you're not aware of what changed, doesn't mean something didn't change 🙂
The running version doesn't tell us much. We need to inspect the non-running version and find out why it's not running.
Can you even run
Copy code
java --version
This may have nothing at all to do with CommandBox even and just be a totally incompat version of Java for the CPU arch
j
Got it. I was wondering if those logs would help determine if it's on the fly java or not
Copy code
java --version
openjdk 11.0.23 2024-04-16
OpenJDK Runtime Environment Temurin-11.0.23+9 (build 11.0.23+9)
OpenJDK 64-Bit Server VM Temurin-11.0.23+9 (build 11.0.23+9, mixed mode, sharing)
b
It's not. It was using whatever was in
/opt/java/openjdk/bin/java
👍 1
I put your error message into Google and it returned zero results 😆
j
Gotta love when that happens lol
Bleeding edge of M3 issues 😛
b
I would focus on searching message forums for that error and "M3"
I don't think this is going to be anything for us to "fix" in our docker containers, outside of possibly updating to a newer version of Java
Java 11 is a little old too
Maybe try updating the Java version inside the container as a test
j
I have spent a fair amount of time searching for general JVM issues with Apple silicon. I'll try to get more specific
Off the otp of your head do you know an easy way to update that? I was trying to find sites that I can wget the downloader for but was struggling
Maybe I'll just check what's on apt first before getting to crazy
b
I assume apt
You can look at our docker files to see how we go about installing it in the first place
j
Yup it's definitely plentifully available on apt. Ah nice, thanks for that tip!
Moved over to the
ortussolutions/commandbox:jdk17
image and it sort of works. It'll run for a while and I can use my application but it randomly crashes then restarts. It feels like progress lol. I think the big difference now is that it will just keep restarting until it works. So this can suffice locally. We run our production containers on good ol arm64 so no issues there
j
If you do a
docker image inspect ortussolutions/commandbox:latest
what does it show as the image arch? One of the most common issues I’ve see with the images running on ARM is when someone upgrades to an ARM machine from an x86 one and the arch of the images in the restored backup stays pinned to x86
j
Thanks for following up @jclausen. Your comment here made something click in my brain that I have a flawed understanding of how to use Docker in a multi-architecture setup. I assumed I could point the platform at --platform linux/amd64 when I build on Mac, keeping it the same architecture that we deploy on (Linux/amd64), but it doesn't seem to work that way. I ended up leveraging docker buildx and now have support for arm & amd. Builds successfully in our pipeline and on our local systems so we're back up and running! Thanks again for your guys help.
👍 1