Has anyone had problems with fusionreactor installed by commandbox? We used to use it all the time, I just went back to turn it on in our dockerfile, and now instances won't startup because of the error:

Error occurred during initialization of VM
Could not find agent library /app/server//fusionreactor/libfrjvmti_x64.so in absolute path, with error: Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by /app/server//fusionreactor/libfrjvmti_x64.so)

This is ontop of ortussolutions/commandbox:jdk11-alpine-3.6.2

@Jordan Clark Did you check to see if that file is there?

it is a newer version of commandbox-fusionreactor, fusionreactor itself, and the docker image

Ok, so go back and see if the previous version works

Is there an box env var I can set to trigger verbose output

It's on by default in the ortus images

Odd its not output anything, maybe "Error occurred during initialization of VM" indicates the error is before commandbox can output anything. So the file does exist:

/app/server/fusionreactor/libfrjvmti_x64.so

I wonder if the double "//" in the error is the issue:

/app/server//fusionreactor/libfrjvmti_x64.so

That's possible. Not sure why it wouldn't have caused an issue before

When I examine the startup-final.sh file I see:

exec /opt/java/openjdk/bin/java \
        '-Duser.timezone=UTC' \
        '-XX:ReservedCodeCacheSize=256m' \
        '-Xmx6144m' \
        '-XX:+UseG1GC' \
        '-javaagent:/app/server//fusionreactor/fusionreactor.jar=name=Admin-Portal-Bang,address=0.0.0.0:8088,external=false' \

Well yes, that's what I would expect to see

In my docker file:

ENV BOX_SERVER_APP_SERVERHOMEDIRECTORY=/app/server

But this code has run fine for years so I'm not sure what would have changed overnight

Weird. I manually updated startup-final.sh to fix the "//" now the error is:

Error occurred during initialization of VM
Could not find agent library /app/server/fusionreactor/libfrjvmti_x64.so in absolute path, with error: Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by /app/server/fusionreactor/libfrjvmti_x64.so)

and at the same time I can verify the file is there:

less /app/server/fusionreactor/libfrjvmti_x64.so

wait a minute, I think this is a red herring

its alpine

ld: command not found

stupid alpine

Yeah I just updated to see if that would resolve it, alpine-3.7.6

I'm actually trying to recall if FR supports alpine in their debugger libs

Its been about a year, but we used to use FR on alpine in the past

I think that's what it's called

That looks like the root cause

☝️ Yep, there you go

Are any fusionreactor people active in this slack?

sometimes

Thanks for your help pin pointing this

I've prolly asked them about this before and they said not enough people used alpine to support it, lol

I tried adding dependencies

apk add gcompat

and/or

apk add libc6-compat

it gets passed the missing library, but every time the JDK crashes hard

A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000000004f026, pid=331, tid=332
#
# JRE version:  (11.0.16.1+1) (build )
# Java VM: OpenJDK 64-Bit Server VM (11.0.16.1+1, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# C  0x000000000004f026

Interesting

Yup

The error is the path " /app/server//fusionreactor/libfrjvmti_x64.so" this is the wrong path.. as // is a literal path set. So try modifying your config so its just references/app/server/fusionreactor/...

Read above, he did that.

he said he modified the file, he needs to check the permissions on the file as well

Read the thread 🙂

the real error is LD is a kernal module used to handle aliases at the io level, so he doesnt have 'ld", which is kind of a big deal. Tells me, without even bothering to look it up, the installer is looking for POSIX standard install which java is geared for and what ever distro he is using, is not.

No, he's running it on MUSL linux and the gcc libs aren't present which is what the debugger lib is linked to, like I said

like i said, POSIX compliant vs some kind of weird halted style throw back

You are correct RHEL or Debian would have worked, but people like Alpine because it's small

debian and rhel are small enough to run entire countries on. People need to get over storage sizes as storage is ultra cheap

ortussolutions/commandbox:jdk11-alpine is an official ortus image, its not a linux from scratch project

Yeah, we offer Debian and Alpine containers based on what people want

@bdw429s yeah, first reply was simply to disable debugging library: https://commandbox.ortusbooks.com/embedded-server/fusionreactor#debugger-libs Alpine is missing the Glibc libraries required for the debugger. If you disable the libs with the instructions I sent earlier, you will still have monitoring and some system metrics. Alpine is stripped back from an architecture perspective so getting it to have full monitoring capabilities is difficult, if you want full capabilities I would recommend switching to something like Debian or CentOS.

lol, well obviously that would make the error go away, lol

Yup thats what I did

alpine is all but a halted kernel image. Better off from a security and a size prospective using FreeBSD, as its performance is legendary, or at least "good enough" to run major streaming companies on.