Infrastructure at your Service

Morgan Patou

Documentum – xPlore installer refuses to start because of ‘Multiple launches’

While working with xPlore, you might have faced before a message saying that an xPlore installer refused to start because it is not allowed to run multiple instances at the same time. This could have happened while running any installer: binaries, patches, dsearch, aso… However, when checking the processes, there is only one running and that’s the one you just started.

 

That’s actually a very old and very persistent issue since it’s there at least since xPlore 1.2 and it’s still the same for the latest version. It is already documented in the OpenText KB7867004. In the KB, only xPlore 1.2 to 1.4 are mentioned and only for a xPlore patch installation. The truth is that it’s still true even for the most recent 16.x version and it’s not limited to patches, you might have that for all installers as I mentioned before, because they are all built using the same soft. I wanted to talk about this issue in this blog because it’s probably something that might happen more and more with the DevOps approach. With ordinary Virtual Machines, you might face this once but then it’s fixed, you won’t see it again. In the DevOps world, if it’s not done properly, it’s something that might repeat a few times until it’s really fixed at the root of the issue.

 

So what’s this issue? As mentioned, it actually comes from the installer itself. You probably know that OpenText inherited from Dell and EMC before that of the “InstallAnywhere” installers. The issue here usually comes when there are wrong permissions on the home folder. The InstallAnywhere creates hidden files/folders under the home folder (E.g.: ~/.com.zerog.registry.xml) for the installation which register all components present. In case it’s not possible to create that, the installer fails to start with the message I mentioned above. This is something that you might be facing while using containers because of several things. Here are some potential examples:

  • the home folder of your installation owner (xplore or whatever the name) was left with root permissions
  • xPlore binaries were installed properly in an image but then at the runtime, it wasn’t mounted properly (if it’s a volume)
  • something changed the permissions

 

To replicate the issue quickly, you can just start the Dsearch installer for example. Here I’m using a silent properties file because there is no GUI:

[[email protected] ~]$ $XPLORE_HOME/setup/dsearch/dsearchConfig.bin LAX_VM "$JAVA_HOME/bin/java" -f $XPLORE_HOME/setup/FT_Dsearch.properties
Preparing to install
Extracting the installation resources from the installer archive...
Configuring the installer for this system's environment...

Launching installer...

Multiple launches of this installer is not allowed. It will now quit.
[[email protected] ~]$
[[email protected] ~]$ ls -ld $HOME
drwx------ 1 root root 4096 Mar 21 15:29 /home/xplore
[[email protected] ~]$
[[email protected] ~]$ ls -l $HOME
ls: cannot open directory /home/xplore/: Permission denied
[[email protected] ~]$

 

If you have the above behavior, then you just need to correct the permissions on the home folder. If this is inside a container (docker or other) or inside a Kubernetes pod for example, then you will need to find where exactly the issue is coming from and fix it there but for that I cannot help you because it depends on the infrastructure you put together. To validate the solution quickly:

[[email protected] /]# chown -R xplore:xplore /home/xplore
[[email protected] /]#
[[email protected] /]# su - xplore
[[email protected] ~]$
[[email protected] ~]$ $XPLORE_HOME/setup/dsearch/dsearchConfig.bin LAX_VM "$JAVA_HOME/bin/java" -f $XPLORE_HOME/setup/FT_Dsearch.properties
Preparing to install
Extracting the installation resources from the installer archive...
Configuring the installer for this system's environment...

Launching installer...

[[email protected] ~]$
[[email protected] ~]$ grep "\.version" $XPLORE_HOME/installinfo/instances/dsearch/PrimaryDsearch.properties
ess.version=16.4.0000
appserver.version=9.0.1
[[email protected] ~]$

 

The error message could be clearer, mentioning that there is a permission issue with the home folder but at least, it’s not failing silently. I guess that’s at least a good point.

 

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Morgan Patou
Morgan Patou

Technology Leader ECM & Senior Consultant