http://coldfusion.com logo
Join Slack
Powered by
Having an issue with FusionReactor with command bo...
# docker
d
Having an issue with FusionReactor with command box when building my container for arm64. All is going fine until FusionReactor decides it wants to use libfrjvmti_x64.so - which is the amd64 version. Can't see anything in any docs that mentions specific instruction / flags for arm or am I missing something obvious? If I don't do a box install commandbox-fusionreactor in my docker build the arm container works as expected
l
This was fixed pretty recently in 
commandbox-fusionreactor
(Brad added arch detection) and in the libs that are downloaded by the 
fusionreactor
forgebox package.
Make sure you're using the latest 
commandbox-fusionreactor
(4.1.1) and it should work
If you rebuild your package without caching, that might help.
My Dockerfile includes: 
RUN box install commandbox-fusionreactor
So you shouldn't need any explicit config to make the ARM build work.
d
thanks @Leon Miller-Out I thought that was the case - I'm fairly sure I have the latest command box and have forced an update but will check
b
Yep, SHOULD be working. Double check your version of the module
Also, show us the console output of the server starting-- specifically the fusionreator part
There is debugging in there that tells us what CPU is detected for LInux
You should see
Copy code
Linux detected for debug libs.
or
Copy code
Linux ARM detected for debug libs
d
seems the detection isn't picking up: 
| ******************************************
| * CommandBox FusionReactor Module Loaded * | ****************************************** | Your FusionReactor version [8.7.7] is already the latest, skipping ins | tallation. | Pin an exact FusionReactor version to skip this Forgebox check. | FusionReactor debug libs added. | Linux detected for debug libs.
b
@dougcain or you have an older version of the module šŸ™‚
Did you check that yet?
Also run this from the CommandBox CLI
Copy code
env show os.arch
and tell me what it outputs
The module detects an ARM CPU architecture when that java system property contains the text 
arm
or 
aarch
in it
d
I forced it to be 4.1.1 which seems to be the current - I am building the container with FROM --platform=arm64 ortussolutions/commandbox:latest
when you say module I assume you mean commandbox-fusionreactor
b
Yup, that's the module we're talking about šŸ˜‰
šŸ™ƒ 1
d
had to turn commandbox-fusionreactor off so the container ran but: 
CommandBox> *env show* os.arch
aarch64
b
Looks like arm to me. The console output above, was that from before or after you updated the module to the latest
Also, you don't need to turn all of FR off-- just turn off the debugger
Copy code
server set fusionreactor.debugEnable=false
The code in the module for this is pretty straight forward
Copy code
if( systemSettings.getSystemSetting( 'os.arch', '' ).findNoCase( 'arm' ) || systemSettings.getSystemSetting( 'os.arch', '' ).findNoCase( 'aarch' ) ) {
						if( fileExists( ARMDebuggerLibPath ) ) {
							logDebug( 'Linux ARM detected for debug libs.' );
							debugLib = 'libfrjvmti_aarch64.so';	
						} else {
							logDebug( 'Linux ARM detected, but no lib available.  Disabling FR debugger.' );
						}
					} else {
						logDebug( 'Linux detected for debug libs.' );
						debugLib = 'libfrjvmti_x64.so';	
					}
If you're on the latest version of the module, you have to be hitting one of those code paths
d
after - will try with just the debugger off
b
You can verify that code is on lines 202-212 in
Copy code
.CommandBox/cfml/modules/commandbox-fusionreactor/ModuleConfig.cfc
inside the container
if you're seeing 
Linux detected for debug libs.
in the console, that means 
systemSettings.getSystemSetting( 'os.arch', '' ).findNoCase( 'aarch' )
is returning false
d
starts fine with the debugger off still get aarch64 in the os.arch
looks like it's not seeing aarch64 for some reason - with the debugging on it breaks and shows: 
| Pinned FusionReactor version [8.7.7] is already installed, skipping in
| stallation. | FusionReactor debug libs added. | Linux detected for debug libs.
something for tomorrow for me now - does seem quite odd
b
Yup
you can just edit that moduleconfig.cfc file directly and put in some debugging that shows what the output of 
systemSettings.getSystemSetting( 'os.arch', '' )
when the server starts and try to figure out why it's not recognizing the CPU as arm
d
will let you know what I find, thanks for the pointer
šŸ‘ 1
@bdw429s just checking i'm in the right place - I'm looking in /usr/local/lib/CommandBox/cfml/modules/commandbox-fusionreactor/ModuleConfig.cfc as it doesn't have any checking for arm / aarch.
b
yes, that's the place
That means the module is not on the latest version
How did you go about checking the version prior?
d
i'm using box install commandbox-fusionreactor@4.1.1
b
Should be
Copy code
list --system
What is the 
--verbose
output of that install command?
d
ahh that will be why - commandbox-fusionreactor (4.0.9)
b
My guess is the install is a no-op and there's debugging messages in the verbose output telling you why
d
must be pinned somehow - not sure where though
b
Copy code
box install commandbox-fusionreactor@4.1.1 --verbose
ā˜ļø What is the output of that command?
@dougcain
d
CommandBox> box install commandbox-fusionreactor@4.1.1 --verbose
Removing extra text [box ] from start of command. You don't need that here. āˆš | Installing package [forgebox:commandbox-fusionreactor@4.1.1] |--------------------------------------------------------------------------- | Package found in local artifacts! | Decompressing... | Shell will be reloaded after installation. | /usr/local/lib/CommandBox/cfml/modules/commandbox-fusionreactor//box.json updated with dependency. | Installing to: /usr/local/lib/CommandBox/cfml/modules/commandbox-fusionreactor//modules/commandbox-fusionreactor | -> 14 File(s) Installed | -> 0 File(s) ignored | Eureka, 'commandbox-fusionreactor@4.1.1' has been installed! |---------------------------------------------------------------------------
but weirdly
Copy code
list --system
Dependency Hierarchy for CommandBox System (1.0.0)
ā”œā”€ā”¬ commandbox-cfconfig (1.6.3)
ā”‚ ā””ā”€ā”¬ cfconfig-services (1.14.0)
ā”‚   ā”œā”€ā”€ lucee-password-util (1.0.3)
ā”‚   ā”œā”€ā”€ coldbox ()
ā”‚   ā”œā”€ā”€ testbox ()
ā”‚   ā”œā”€ā”¬ JSONPrettyPrint (1.4.1)
ā”‚   ā”‚ ā”œā”€ā”€ coldbox ()
ā”‚   ā”‚ ā””ā”€ā”€ testbox ()
ā”‚   ā”œā”€ā”¬ adobe-password-util (1.0.8)
ā”‚   ā”‚ ā””ā”€ā”€ propertyFile (1.2.0)
ā”‚   ā”œā”€ā”¬ semver (1.2.5)
ā”‚   ā”‚ ā””ā”€ā”€ testbox ()
ā”‚   ā””ā”€ā”€ propertyFile (1.2.0)
ā”œā”€ā”¬ commandbox-fusionreactor (4.0.9)
ā”‚ ā””ā”€ā”€ commandbox-fusionreactor (4.1.1)
ā””ā”€ā”¬ commandbox-dotenv (2.1.1)
  ā””ā”€ā”€ propertyFile (1.2.0)
b
Hmm, somethings not right
d
fusion reactor is appearing twice
b
The package is showing up twice, nested under it'self!
I've never seen that before
d
cool huh?
b
Can you uninstall and install fresh?
d
where can you pin versions of modules so I can go check around
b
Explain?
Also, what folder did you run that install command in?
Copy code
pwd
d
i'm guessing when its build even though i specify 4.1.1, 4.0.9 is being installed (pinned somehow)
b
I'd worry more about where the package is installing to
d
/usr/local/lib/CommandBox/cfml/modules/commandbox-fusionreactor/
b
4.1.1 would have properly replaced 4.0.9 had it installed into the correct location
d
same output if i run list --system at /app
b
So, it apperas CommandBox didn't recognize it as a commandbox module and just dumped it in the current folder
That's odd
d
will clean up and try from scratch
b
Except, it did because I see
Copy code
Shell will be reloaded after installation.
I think this may be an odd behavior that only happens if you're running the commands from that folder
I've never run system installs from a folder already inside the system folder
I have a feeling, if CommandBox were just cd'd into 
/app
or something, it would work as expected
d
just did that and it looks better now, will see what happens when I restart the container
b
Yep, here's the logic
Copy code
// CommandBox Modules
				} else if( packageType == 'commandbox-modules' ) {
					var commandBoxCFMLHome = fileSystemUtil.normalizeSlashes( expandPath( '/commandbox' ) );
					arguments.packagePathRequestingInstallation = fileSystemUtil.normalizeSlashes( arguments.packagePathRequestingInstallation );

					// If we're already in the CommandBox (a submodule of a commandbox module, most likely)
					if( arguments.packagePathRequestingInstallation contains commandBoxCFMLHome ) {
						// Then just nest as normal.
						installDirectory = arguments.packagePathRequestingInstallation & '/modules';
					} else {
						// Override the install directories to the CommandBox CFML root
						arguments.currentWorkingDirectory = commandBoxCFMLHome;
						arguments.packagePathRequestingInstallation = commandBoxCFMLHome;
						installDirectory = expandPath( '/commandbox/modules' );
					}
read through the comments and you'll see where it went wrong
ā€¢ CommandBox checks the type of package its installing ā€¢ if it's a commandbox module, it swaps out the installation path to point to Commandbox's modules folder ā€¢ UNLESS the current path is already in a subfolder of the system modules directory-- then it just uses whatever the heck the current directory is to install into
Since you had `cd`'d into a system module already for whatever reason, you were tricking CommandBox into doing the weird install in a sub-folder bit
d
what I don;t get is why it install 4.0.9 even though i'm telling it to do 4.1.1 in the build script
will build from scratch and disable the docker cache again
b
Not sure, you'd have to review how your build works and find where and how you install the module in the first place
It's possible you haven't actually re-built the container since you changed it. Just stopping and starting a container, doesn't rebuild it
l
I've just been struggling with that! I thought that 
docker-compose build
would do it, but I just learned that I need to run 
docker-compose down
to really remove the current version of my containers.
d
I think that's what caused my confusion aswell - all working as expected now - thanks very much for bearing with me šŸ™‚
4 Views
Open in Slack
PreviousNext
Powered by