When running java-applets as normal user an initial error message is printed: java.util.prefs.FileSystemPreferences$3 run WARNING: Could not create system preferences directory. System preferences are unusable. Every 30 secs an additional error message is printed: java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode WARNING: Could not lock System prefs.Unix error code 4. strace showed the reason: 16844 stat64("/etc/.java/.systemPrefs", 0xbfffd380) = -1 ENOENT (No such file or directory) 16844 stat64("/etc/.java/.systemPrefs", 0xbfffd350) = -1 ENOENT (No such file or directory) 16844 mkdir("/etc/.java/.systemPrefs", 0777) = -1 ENOENT (No such file or directory) Reproducible: Always Steps to Reproduce: Start i.e. opera from the command line with java/blackdown enabled as normal user. To enable java/blackdown in opera go into Preferences/Multimedia, check the java-box. The path to be entered is /opt/blackdown-jdk-1.4.1/jre/lib/i386/ Solution (to be done as root): # mkdir -p /etc/.java/.systemPrefs # touch /etc/.java/.systemPrefs/.systemRootModFile # touch /etc/.java/.systemPrefs/.system.lock Actual Results: The error messages disappeared Portage 2.0.48 (default-x86-1.4, gcc-3.2.2, glibc-2.3.1-r4) ================================================================= System uname: 2.4.20-gentoo-r5 i686 Pentium III (Coppermine) GENTOO_MIRRORS="http://www.fhh.opensource-mirror.de/gentoo.org/ http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config /service /var/lib/svscan /usr/X11R6/lib/X11/xkb" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/mnt/portage/distfiles" PKGDIR="/mnt/portage/packages" PORTAGE_TMPDIR="/mnt/portage/tmp" PORTDIR_OVERLAY="/usr/local/portage" USE="x86 oss crypt cups encode gif jpeg kde gnome libg++ mikmod mmx mpeg ncurses nls pdflib png spell truetype xml2 zlib gdbm berkdb slang readline svga X sdl gpm tcpd pam libwww ssl python esd imlib gtk qt motif opengl -3dnow -apm -arts -avi curl doc emacs flash gd imap innodb -java ldap maildir mozilla odbc -oggvorbis perl postgres -quicktime samba scanner tcltk tetex tiff wmf -xmms -xv" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-mcpu=pentium3 -O3 -pipe" CXXFLAGS="-O2 -mcpu=i686 -pipe" ACCEPT_KEYWORDS="x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" FEATURES="sandbox ccache"
This is also visible in Mozilla under Tools->Web Development->Java Console, as it tries to save the prefs every 30 seconds as well. Adding those directories (chmoded 755) and those files (chmoded 644) does the trick. This whole issue has a sun webpage and this: http://www.allaboutbalance.com/disableprefs/index.html devoted to it.
Firstly, are system preferences for a browser plugin actually desirable ? If so, you can create those directories and files to remove the error and allow saving of applet preferences system-wide, but I would discourage that being done on a universal basis. Secondly, applet preferences are still saved in ~/.java/.userPrefs/ Thirdly, the problem lies in upstream code, since there is a fallback mechanism that goes from system to user, a SecurityException should not be thrown, nor should that error message be displayed in a Timer, once on initialization is enough.
Moving this again to java@gentoo.org, so everyone out there can help.
Created attachment 22644 [details] creates systemPrefs, for blackdown-jdk-*.ebuild/src_install
The problem is not limited to applets. Move /etc/.java away and run: class SystemPrefsTest { public static void main(String[] args) { System.out.println(java.util.prefs.Preferences.systemRoot()); } } with blackdown-jdk as non-root to see the same warning. Some rationale from http://www.jcp.org/aboutJava/communityprocess/first/jsr010/usage.html: "The use of system preferences should be rare compared to user preferences. We anticipate that they will be used chiefly to store configuration information (such as what version of a program is installed or what resources it uses). In typical Java platform implementations, ordinary users will not be able to modify system preferences as backing stores typically demand administrative privileges to modify system-wide data." While it may not be desirable to let applets read system config information, it requires root to make it available. Well, root needs to be careful anyway, doesn't he? Googling around I found Mandrake (http://rpms.mandrakeclub.com/rpms/MandrakeClub/test/9.1/i586/j2re-1.4.1_01-5mdk.i586.html) and SuSE (http://www.suse.de/us/private/products/suse_linux/i386/packages_personal/java2-jre.html) do install a basic systemPrefs setup in /etc/.java/. The sun-jdk-1.4.2 ebuilds use $JAVA_HOME/.java which is the second option. I dunno about the other distros. See the attachment. The program above may serve as a test case.
Created attachment 23335 [details] modified java-config ebuild to add those files I think java-config should bring this files, since it is DEPENDed on in every jdk/jre
Created attachment 23336 [details] fixed typo
I would simply refer back to my previous comments here, the _problem_ lies in upstream code, there is little to no reason in most cases for system-wide preferences, and if system-wide preferences cannot be written or read, user preferences are used instead which is preferable in most cases. I would advise marking UPSTREAM and e-mailing upstream on the affected JRE/JDKs asking why a SecurityException is thrown repeatedly in a timer when there is a fallback mechanism anyways. But regardless, creating those dirs/files for everyone is not something that should be done without extensive testing since multiple JRE/JDKs may use the same files which might create incompatibilities or inconsistencies.
The .systemPrefs directory doesn't need to be in /etc at all. For blackdown-jdk-1.4.1, it needs to be in the /opt/blackdown-jdk-1.4.1/jre directory. For sun-jdk-1.4.2.03 it seems to need to be in /opt/sun-jdk-1.4.2.03.
I did a little bit more testing with this. In mozilla-1.6, the error doesn't show up on the console you ran mozilla from anymore. It only shows up in the java console. This problem has also been fixed with sun-jdk-1.4.2.03, because it now creates the ~/.java/.userPrefs directory instead of relying on the $JAVA_HOME/.systemPrefs that it can't write to. blackdown-jdk-1.4.1 still requires some sort of .systemPrefs or it will start throwing errors. The simplest way to make it stop is to create an empty .systemPrefs directory in /opt/blackdown-jdk-1.4.1/jre. The directory does not need to contain any files or be writable by the user to stop the error. Not suprisingly, blackdown-jre-1.4.1 has the same bug which can be fixed in a very similar manner. An empty /opt/blackdown-jre-1.4.1/.systemPrefs is all it takes.
Created attachment 25789 [details, diff] diff for fixed blackdown-jre ebuild This diff includes the fix for the FileSystemPreferences exception in blackdown-jre-1.4.1. It just makes the empty directory /opt/${P}/.systemPrefs. I also removed the keywords and added ~x86, because I've only tested it on x86.
Created attachment 25790 [details, diff] diff for fixed blackdown-jdk ebuild This patch is very similar to the one above. Because the jre is a subset of the jdk, I create the directory after the jre directory has been copied.
Comment on attachment 25789 [details, diff] diff for fixed blackdown-jre ebuild I was wrong, this doesn't fix the bug. This prevents the initial Exception, but not the one that is thrown every thirty seconds after running an applet.
Comment on attachment 25790 [details, diff] diff for fixed blackdown-jdk ebuild I was wrong, this doesn't fix the bug. This prevents the initial Exception, but not the one that is thrown every thirty seconds after running an applet.
This issue is also valid with Sun's JDK 1.4.2_07.
I've run into the same problem here on sun-jdk-1.5.0.06 (we have /opt mounted ro, so the default behavior doesn't work for us). I'm not sure about blackdown, but Sun's behavior is *not* creating the .systemPrefs folder if it doesn't exist in the default /etc/.java folder. The solution _if_ you want the system prefs in /etc is to make a .systemPrefs folder in /etc/.java by hand, _or_ if you want to put it someplace else, define the system preference java.util.prefs.systemRoot to point someplace else as long as that location _also_ has a .systemPrefs folder created by hand, otherwise Sun will override your choice and go back to ${JAVA_HOME}. This sounds like a Sun bug to me... they could at least try and make the initial directories before giving up IMHO.
This is an old bug referring to ebuilds that have been removed form the tree, is there a reson for keeping it open?
(In reply to comment #17) > This is an old bug referring to ebuilds that have been removed form the tree, > is there a reson for keeping it open? Thank you for the reminder.