I installed DevTest in Linux machine by using "root" user of the Linux. And I started Enterprise Dashboard and Registry from "root" user of Linux as services. After logging into the Linux console by using another user who does not have "root" privilege and I tried to start DevTest Workstation and to log into Registry, then I got a Database Error dialog like below:
and after clicking the "Yes" button, DevTest Workstation was terminated.
By checking the workstation.log, I found the error message like below:
2017-06-15 02:09:50,979Z (22:09) [main] ERROR com.itko.lisa.test.SiteProperties - Unable to read properties file for LISA_LOCAL_PROPERTIES
java.io.FileNotFoundException: $LISA_HOME/locks/.local.properties.lock (Permission denied)
at java.io.RandomAccessFile.open0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at com.exe4j.runtime.LauncherEngine.launch(Unknown Source)
at com.install4j.runtime.launcher.UnixLauncher.main(Unknown Source)
I tried to start DevTest Workstation, and log into a Registry running in a different server. However, I got the same error dialog.
This dialog appears after logging in to Registry from DevTest Workstation. The title of the dialog is "Database Error", but this is a permission problem of DevTest installed directories and files.
The sequence of events is as follows:
- DevTest Workstation process checks if DevTest Workstation process can access .lisa.properties.lock, .local.properties.lock and .site.properties.lock files in $LISA_HOME/locks directory for reading and writing or not
- If step 1 is "no", then DevTest Workstation does not start to read lisa.properties, local.properties and site.properties files
- Because of the result of step 2, DevTest Workstation process does not have the database information to connect
- The "Database Error" dialog appears
This problem can occur in the Windows Operating System with these conditions below:
- DevTest installation was done by the "Administrator" in the Windows Operating System.
- On the same machine, the user logs into the Windows with a Windows user which does not belong to the "Administrators" group and starts DevTest Workstation
Changing the permission of .lisa.properties.lock, .local.properties.lock and .site.properties.lock files in $LISA_HOME/locks directory will avoid the "Database Error" dialog and the error messages workstation.log, but these files are used for interprocess concurrency. So changing the permission of these files can't be recommended.
If the Linux user for starting DevTest Workstation can be "root", then using the "root" user for starting DevTest Workstation is one of the solutions.
But if the Linux user for starting DevTest Workstation must not be "root", then solutions are based on the Installation Type when installing. There are two Installation Types like below:
- If DevTest was installed with Local Installation Type (Default Installation Type), then please uninstall DevTest and install DevTest with Shared Installation Type.
- If DevTest was installed with Shared Installation Type, then please check if the Linux user which started DevTest Workstation has the lisa.user.properties file in $USER_HOME.
If the Linux user does not have lisa.user.properties file in $USER_HOME, then
A. Copy lisa.user.properties file from the $LISA_HOME to $USER_HOME B. Open the $USER_HOME/lisa.user.properties file by using a text editor C. In the $USER_HOME/lisa.user.properties file, the property named lisa.data.dir is defined as $LISA_HOME directory, so change this value to the directory that the Linux user has the write access D. Save the $USER_HOME/lisa.user.properties file
If the Linux user has lisa.user.properties file in $USER_HOME, then
E. Open the $USER_HOME/lisa.user.properties file by using a text editor F. Change the lisa.data.dir value to the directory that the Linux user has the write access
If the same problem occurs in the Windows Operating System, the resolution of the problem is almost the same except for the way the file system is represented, the way the environment variables are represented and the "Administrator" user ("root" user in Linux).
Please read the following link for Shared Installation Type and settings: