Problem getting started, ServerEngineService.install() fails

Communities CommandBox CLI
1

I am having a lot of trouble getting started with CommandBox. The built in Lucee 4.5 server is working for me when I run server start, but I want to be able to use Lucee 5 and ACF 10.

Fresh install of CommandBox 3.2 in my home directory, Ubuntu 16.04. When I run something like server start cfengine=adobe@10 name=A10, it downloads the zip file to artifacts folder. I can manually extract this zip file and confirm the WAR file inside. But then on line 194 in ServerEngineService: zip action="unzip" file="#thisFile#" destination="#installDetails.installDir#" overwrite="true"; It tries to unzip [the adobe.zip in artifacts? the Engine.war in adobe.zip?] but crashes here with “No such file or directory.” I have ~/.CommandBox/server/SERVER/adobe-10.0.20.299202, an empty directory.

I was able to get both servers working, briefly, by manually extracting the contents of the Engine.war files into respective folders in /server. But when I restart the server, it creates a new GUID-named folder under /server, I lose my configurations and need to extract the Engine.war again.

Stack traces for attempting to start up ACF10 and Lucee5:

2

> I am having a lot of trouble getting started with CommandBox

Can you try running box as root? It should work as your user, but I want to rule out any permission issyes. Also, do you have any funky settings or ubuntu permissions configured on your machine? Please check the ~/.CommandBox log file too for clues. You can run “system-log | tail”.

What exact release of Ubuntu are you using? It’s possible there’s something crazy on the latest version.

> But then on line 194 in ServerEngineService: `zip action=“unzip” … [it] crashes

Actually, that’s not the line it’s crashing on. That’s the code that doesn’t seem to be actually unzipping anything, but the error in your stack traces happens right after in another function call that actually attempts to use the exploded WAR (that somehow doesn’t exist)

> It tries to unzip [the adobe.zip in artifacts? the Engine.war in adobe.zip?]

There’s two unzip operations. The first happens as part of the packageService.install() that “installs” the cfengine (adobe.zip) into a temp directory. The second unzip is when we take the WAR file in the temp directory and unzip it into the server directory. Come to think of it, either one of those unzip operations could be to blame. Can you comment out the directoryDelete() on line 199 of the ServiceEngineService in ~/.CommandBox/cfml/system/services/ (run “reload” to reload the shell after editing the CFC). Try again and then look in the CommandBox temp directory that’s listed to see if the adobe.zip artifact is unzipping properly. make sure the Engine.war isn’t 0k or something.

> But when I restart the server, it creates a new GUID-named folder under /server,

It’s a hash, not a GUID-- but that’s weird, I would actually expect that to work as long as you put it in the correct folder. The hash is based off the web root of the server plus the server name, so if you manually unzipped the files and then started the server with a different name, it would generate a new hash. Every time you start a server, it does a quick check to see if the server is already unzipped and skips if it’s sees the files. That’s where the “WAR/zip archive already installed.” message comes from on line 172 of ServerEngineService.cfc.

Let me know the exact Ubuntu version and I’ll try to reproduce. The servers are all starting fine for me on my Windows machine and I’ve never heard of this reported, so it has to be something funky going on. I could debug it directly, but I’d need access to your box.

Thanks!

~Brad

3

Hey Brad, hope you enjoyed the weekend.

Eureka, check this out:

ServerEngineService.cfc line 194:
zip action=“unzip” file="#thisFile#" destination="#installDetails.installDir#" overwrite=“true”;

should instead be:
zip action=“unzip” file="#theArchive#" destination="#installDetails.installDir#" overwrite=“true”;

This solves my issues.

4

Whoa, crazy! I have this loop right above that grabs the last .zip or .war file inside the zip:

var theArchive = ‘’;
for( var thisFile in directoryList( thisTempDir ) ) {
if( listFindNoCase( ‘war,zip’, listLast( thisFile, ‘.’ ) ) ) {
theArchive = thisFile;
}
}

Somehow that must have always worked based on the order the files were pulled from the file system such that the archive was always last. I assume #thisFile# probably pointed to the box.json in your case which would be the last iteration of the loop.

Good catch! I’m committing a fix for that right now.

Thanks!

~Brad

ColdBox/CommandBox Developer Advocate
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com