Environment
Microsoft Windows Server 2003 Standard Edition
Microsoft Windows 2000 Server
Microsoft Windows XP Professional
RedHat Linux
Solaris 9
Situation
Why am I unable to run the Control Center (5.1.1) on a Windows
machine with a non-administrator user (a Domain Admin performed the
installation)?
Resolution
The following incident may occur...
Can not get past the splash screen unless the java.exe process is stopped from Task Manager, upon which a big error dialogue box appeared. Running this from the command-line will also produce the same errors:
Can't load log handler "java.util.logging.FileHandler"
java.io.IOException: Couldn't get lock for log/console_%u.%g.log
java.io.IOException: Couldn't get lock for log/console_%u.%g.log
at java.util.logging.FileHandler.openFiles(FileHandler.java:361)
...
java.lang.RuntimeException: Could not open lock file [C:\Program Files\esecurity5.1.1.0\cfglock].
at com.esecurity.common.communication.Communicator.loadConfiguration(Communicator.java:317)
at com.esecurity.common.communication.Communicator.loadConfigurationWithRetry(Communicator.java:243)
at com.esecurity.common.communication.Communicator.initialize(Communicator.java:586)
at com.esecurity.common.communication.Communicator.getInstance(Communicator.java:90)
at esecurity.common.components.PersistHandler.(PersistHandler.java:28)
at esecurity.common.components.DisplayableObjectPersistHandler.(DisplayableObjectPersistHandler.java:48)
at esecurity.common.components.DisplayableObjectEvent.initializeDefaultInstance(DisplayableObjectEvent.java:99)
at com.eSecurity.Application.AppletMain.(AppletMain.java:210)
at com.eSecurity.Application.AppletMain.login(AppletMain.java:495)
at com.eSecurity.Application.AppletMain.main(AppletMain.java:487)
The second exception is repeated many times and seems to imply that it's unsuccessfully trying to write to this file (this cfglock file doesn't actually exist in the directory).
The problem may be caused by insufficient rights to the ESEC_HOME directory.
Sentinel 5.1.1.0 does require that the user running SCC have read/write access to %ESEC_HOME% and its sub-directory.
Each time SCC is launched, a cfglock file is temporarily created to lock configuration.xml, so that only one process is updating configuration.xml. One example of configuration.xml file being updated when launching SCC is that when SCC is launched the first time, the UUID are updated by each of the process that is run.
Also, since log files are generated while running SCC, the user running SCC needs to write to those log files. The log file location can be configurable from .properties file, but cfglock file is in the same directory as configuration.xml, which is recommended to be at %ESEC_HOME%.
Can not get past the splash screen unless the java.exe process is stopped from Task Manager, upon which a big error dialogue box appeared. Running this from the command-line will also produce the same errors:
Can't load log handler "java.util.logging.FileHandler"
java.io.IOException: Couldn't get lock for log/console_%u.%g.log
java.io.IOException: Couldn't get lock for log/console_%u.%g.log
at java.util.logging.FileHandler.openFiles(FileHandler.java:361)
...
java.lang.RuntimeException: Could not open lock file [C:\Program Files\esecurity5.1.1.0\cfglock].
at com.esecurity.common.communication.Communicator.loadConfiguration(Communicator.java:317)
at com.esecurity.common.communication.Communicator.loadConfigurationWithRetry(Communicator.java:243)
at com.esecurity.common.communication.Communicator.initialize(Communicator.java:586)
at com.esecurity.common.communication.Communicator.getInstance(Communicator.java:90)
at esecurity.common.components.PersistHandler.
at esecurity.common.components.DisplayableObjectPersistHandler.
at esecurity.common.components.DisplayableObjectEvent.initializeDefaultInstance(DisplayableObjectEvent.java:99)
at com.eSecurity.Application.AppletMain.
at com.eSecurity.Application.AppletMain.login(AppletMain.java:495)
at com.eSecurity.Application.AppletMain.main(AppletMain.java:487)
The second exception is repeated many times and seems to imply that it's unsuccessfully trying to write to this file (this cfglock file doesn't actually exist in the directory).
The problem may be caused by insufficient rights to the ESEC_HOME directory.
Sentinel 5.1.1.0 does require that the user running SCC have read/write access to %ESEC_HOME% and its sub-directory.
Each time SCC is launched, a cfglock file is temporarily created to lock configuration.xml, so that only one process is updating configuration.xml. One example of configuration.xml file being updated when launching SCC is that when SCC is launched the first time, the UUID are updated by each of the process that is run.
Also, since log files are generated while running SCC, the user running SCC needs to write to those log files. The log file location can be configurable from .properties file, but cfglock file is in the same directory as configuration.xml, which is recommended to be at %ESEC_HOME%.