Tag Archives: Experience and Skills

solve java.util.prefs . backingstoreexception error

Thank you for sharing

The server log shows that an error is reported every half a minute:

Mar 29, 2016 10:37:23 AM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode

WARNING: Could not lock User prefs.
Unix error code 2.

Mar 29, 2016 10:37:23 AM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode

WARNING: Could not lock User prefs.
Unix error code 2.

Mar 29, 2016 10:37:23 AM java.util.prefs.FileSystemPreferences syncWorld

WARNING: Couldn’t flush user prefs: java.util.prefs.BackingStoreException: Couldn’t get file lock.

Mar 29, 2016 10:37:23 AM java.util.prefs.FileSystemPreferences syncWorld

WARNING: Couldn’t flush user prefs: java.util.prefs.BackingStoreException: Couldn’t get file lock.

Mar 29, 2016 10:37:25 AM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode

WARNING: Could not lock System prefs. Unix error code 0.

Mar 29, 2016 10:37:25 AM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode

WARNING: Could not lock System prefs. Unix error code 0.

Mar 29, 2016 10:37:25 AM java.util.prefs.FileSystemPreferences syncWorld

WARNING: Couldn’t flush system prefs: java.util.prefs.BackingStoreException: Couldn’t get file lock.

Mar 29, 2016 10:37:25 AM java.util.prefs.FileSystemPreferences syncWorld

WARNING: Couldn’t flush system prefs: java.util.prefs.BackingStoreException: Couldn’t get file lock.

It was harmless enough, but it made me very sad, so I decided to solve it. After many queries, I found that the cause of this problem was that the JDK could not be locked when locking user configuration. In fact, it was a variety of permission problems

Read the following two articles

http://www.ithao123.cn/content-10680341.html

http://www-01.ibm.com/support/docview.wss?uid=swg21515420

I got some inspiration

Then I found that I needed to assign /etc/java operation permission to the tomcat logon user. Since it came with tomcat6, I opened the tomcat6.conf file and found this line:

TOMCAT_USER=”tomcat”

To be lazy, change it decisively to root, and at this point, the problem is solved

Now that’s the point

After all, it is not safe for Tomcat to get the root permission. If the group security check is carried out in the future, the vulnerability will be swept out. Therefore, all privileges of Tomcat users should be assigned:

# chown tomcat:tomcat -R /etc/.java/.systemPrefs

# chown tomcat:tomcat -R /etc/.java

# chown tomcat:tomcat -R /var/lock/subsys/tomcat6

# chown tomcat:tomcat -R /var/log/tomcat6

# chown tomcat:tomcat -R /var/lib/tomcat6

# chown tomcat:tomcat -R /var/cache/tomcat6

# chown tomcat:tomcat -R /etc/rc.d/init.d/tomcat6

# chown tomcat:tomcat -R /etc/logrotate.d/tomcat6

# chown tomcat:tomcat -R /etc/sysconfig/tomcat6

# chown tomcat:tomcat -R /etc/tomcat6

# chown tomcat:tomcat -R /usr/sbin/tomcat6

# chown tomcat:tomcat -R /usr/share/tomcat6

# chown tomcat:tomcat -R /usr/share/java/tomcat6

Then change the logged-in Tomcat user back to Tomcat and restart, and there is still no problem