For instance, if I need to access a compiler, but it’s location is not in the PATH variable, this will be reflected with an error in the build log. So, recognizing this, we change the PATH variable to point to the compiler location. After confirming that the compiler is in the PATH, we go back to running the build. Yet, we still receive the same compiler not found error from the previous build. Everything checks out, yet the build is still not running.

What is going on here?

During the execution of workflow, Meister checks to see if omsubmit is running, and then launches omsubmit if it is not. When omsubmit is launched as a new process it takes a snapshot of the environment variables that are set for the user that ran the build. All subsequent Meister workflows are then run against this “baseline” environment. Any environment variable changes that occur outside of a Meister Workflow will not be picked up, until omsubmit is restarted. This feature of omsubmit can lead to a lot of frustration, if you are not aware of how omsubmit causes environment variables to persist, regardless of changes made to the actual system environment settings. 

Luckily, the fix to this situation is simple – kill omsubmit, and then rerun the build. 

In order to avoid this frustration, make sure that you double check your system environment before you run your build. Make sure all compilers are in the PATH, and any other system wide variables are set. Then, set any build specific variables in the workflow.

However, even if you have the correct versions of Perl and Java installed, you might run into Perl or Java validation errors when you install Meister. The most common cause of these errors is conflicts with Oracle products. Oracle ships with its own version of Perl, which has been optimized to work with the Oracle database. When Oracle is installed, it modifies two environment variables: the PATH variable, and the PERL5LIB variable.

When Meister performs its Perl validation routines during installation, it recognizes the Perl version that Oracle has placed in the PATH. This is where the first conflict arises. Meister validates the Perl installation by running a `perl -v` command, and checking against the output of that command. Oracle’s version of Perl returns an unexpected version number string, and does not pass validation (this is by design, since Oracle’s version of Perl will not work with Meister’s Perl libraries.)

In order to pass Perl validation, then, you will need to modify the PATH variable so that the Oracle’s “bin” directory is no longer in the PATH.

Once you have cleared out references to Oracle Perl from your PATH, you will still run into one more error: Meister installation will hang if the PERL5LIB variable is definied. You will need to remove the PERL5LIB variable when you install Meister.

Openmake Support’s recommendation is to initialize a Meister install from a shell prompt. From inside the shell, modify the PATH variable to remove Oracle’s bin directory (where their perl.exe is installed), and unset the PERL5LIB. Once you have modified the environment, you can run the install of Meister. After Meister installed, you will be able to start it from your normal environment (including Oracle’s environment settings.)

I asked the customer to reinstall, and once again, everything would be working fine… until the machine was restarted. This went on for a few days, until we figured out that the Mojo Uninstaller that was deleting the files. However, it was the Mojo Uninstaller from a previous install that was deleting the files. It was deleting files from beyond the grave! (or the Recycle Bin)

The Mojo Uninstaller is based on a third-party software that stores a list of files that need to be deleted in an obscure location on the file system. Normally, this list is cleared once all files are deleted. However, in the customer’s case, not all files were deleted: the Knowledge Base server was still running during the uninstall, so any .jar files used by the KB Server could not be deleted. Therefore, the “files to delete” list still had these jar files listed. Once these files were freed up (i.e. on restart of the machine) the uninstaller jumped in and deleted the files. Since this list of files is stored in an obscure, relatively inaccessible place, we could not tell the uninstaller to quit uninstalling these files.

So, DO NOT use uninstall.exe when uninstalling Mojo on Windows. Unless of course you like headaches.

“So, Mr. Support Guy, how do I uninstall Mojo?” you ask?

Glad you asked. It’s a simple process:

1. Stop the Knowledge Base server – this will free up the KBServer jar files for uninstalling
2. delete all the files from the directory where you installed Mojo.
3. Delete the omenvironment.properties file.

If you have already uninstalled Mojo using uninstall.exe, and files are mysteriously disappearing from your Mojo install, then we recommend you do the following:

1. Uninstall mojo using the above process.
2. Reinstall Mojo in a different directory, so the uninstaller cannot find the .jar files it wants to delete.

All license requests now need the following information to generate a proper license.kb:

- hostid of the KB Server (see installation guide for how to obtain this for the different OS’s. On windows it’s vol c: and most unix flavors, a derivative of the uname command)

- host names of any Remote Build Servers that are licensed, if any.

- number of named licensed users.

- contact information (name, e-mail and phone number is sufficient)

- whether or not you have a permanent license or are just requesting a demo version.

For more information about licensing, you may also always contact our Openmake sales team.