JDK-6981950 : (prefs) BackingStoreException: Couldn't get file lock
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util
  • Affected Version: 5.0u61,6u23,7,9
  • Priority: P4
  • Status: Resolved
  • Resolution: Cannot Reproduce
  • OS: generic,linux,solaris_nevada
  • CPU: generic,x86
  • Submitted: 2010-09-02
  • Updated: 2023-08-29
  • Resolved: 2016-09-09
Related Reports
Relates :  
Description
Tested against solaris-amd64 on
SunOS vm-v20z-9 5.11 snv_146 i86pc i386 i86pc
Oracle Solaris 11 Express snv_146 X86

java -version
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b02)
Java HotSpot(TM) Server VM (build 17.1-b03, mixed mode)

Test code attached.

To run test:
export JAVA_HOME=/net/.../6u23/promoted/latest/binaries/solaris-amd64
$JAVA_HOME/bin/javac TestRemoveAllSystem
$JAVA_HOME/bin/java TestRemoveAllSystem

Test failed with following exception:

Sep 2, 2010 7:09:16 AM java.util.prefs.FileSystemPreferences$3 run
WARNING: Could not create system preferences directory. System preferences are unusable.
Sep 2, 2010 7:09:18 AM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode
WARNING: Could not lock System prefs.Unix error code -1209014447.
Exception thrown in clearNodes() of Nodes java.util.prefs.BackingStoreException: Couldn't get file lock.
Sep 2, 2010 7:09:19 AM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode
WARNING: Could not lock System prefs.Unix error code -1209010000.
Exception thrown = java.util.prefs.BackingStoreException: Couldn't get file lock.
RemoveAllSystemTest01() Fail
java.util.prefs.BackingStoreException: Couldn't get file lock.
        at java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:715)
        at java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:807)
        at TestRemoveAllSystem.RemoveAllSystemTest01(TestRemoveAllSystem.java:28)
        at TestRemoveAllSystem.main(TestRemoveAllSystem.java:9)

Comments
Seen here with jdk21 / jdk22 when running test sun/tools/jhsdb/JStackStressTest.java (probably concurrently) https://bugs.openjdk.org/browse/JDK-8304938
29-08-2023

Not seen since Feb 2016
09-09-2016

Andrey - one thing to look at is the jdk/test/TEST.ROOT file in the jdk7 or jdk8 repository. You'll see that we have java/util/prefs in the value of the exclusiveAccess.dirs property. That is to ensure that the preferences tests run sequentially as they cannot be run concurrently. There are a few other fixes to prefs too but that might help in your environment.
06-12-2013

Alan, problem is reproducible with both local and network directory. When i try to reproduce this problem by manual execution of failed tests or by execution of testlist without concurrency no fails occurs. When i executed my testlist with concurrency, problem appears again and again with each rerun, sometimes with new failed tests, ie: java_util/prefs/Preferences/SJvmSThread/userRoot/ImportPreferences02 java_util/prefs/Preferences/SJvmSThread/userRoot/GeneralTest/PreferencesPutGet01 As I see problem occurs when several jvm try to execute remove/flush/sync command on the same resource.
06-12-2013

Andrey - as per the previous reports, can you check if the home directory is on NFS?
05-12-2013

See also this discussion: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-September/011512.html
05-10-2012

EVALUATION I think we need more information about the environment. Is the login local or NIS/LDAP? Is the home directory on NFS? I suspect the issue is NFS locking rather than a JDK bug.
08-01-2012