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.
Mar 29, 2016 10:37:23 AM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode
WARNING: Could not lock User prefs.
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