We installed RH6.1 with full-LDAP-Support, so we have only the functional accounts needed by the system in /etc/passwd. Starting a Website containing JAVA generates a bus-error on netscape 4.6 and 4.7 if the user is complete LDAP. If the users account-data is added too /etc/passwd, netscape-JAVA works.
What does your /etc/nsswitch.conf look like?
We only have the user and group-information stored in LDAP and all the other commands which need uid/gid-information seem to work (in contrast to RH5.2 as base-system and multiple pam/ldap-patches added). cat /etc/nsswitch.conf | grep -v "^#" | grep -v '^$' passwd: files ldap group: files ldap hosts: dns services: files networks: files protocols: files rpc: files ethers: files netmasks: files bootparams: files publickey: files automount: files aliases: files sendmailvars: files netgroup: files
If you strace and/or ltrace netscape, what in particular is it doing before it dies? (This is trying to see if there's a configuration workaround. If the problem is in netscape/jdk, there's not much we can do.) If you install the blackdown or IBM jdk and just try and run something, does it have the same problems?
I tried jdk_1.1.7-v3-glibc-x86.tar.gz and it worked. I did some straces and found strange behaviour..... You can access the comeplete traces via http://linux.fh-heilbronn.de/RH/nstrace0[1-4] I did an strace of the netscape-call and got these last lines (nstrace01): uname({sys="Linux", node="becks.stud.fh-heilbronn.de", ...}) = 0 rt_sigprocmask(SIG_BLOCK, [ALRM], [RT_0], 8) = 0 socket(PF_UNIX, SOCK_STREAM, 0) = 28 connect(28, {sun_family=AF_UNIX, sun_path="/var/run/.nscd_socket"}, 110) = -1 ECONNREFUSED (Connection refused) close(28) = 0 --- SIGSEGV (Segmentation fault) --- getpid() = 2018 kill(2018, SIGBUS) = 0 --- SIGBUS (Bus error) --- +++ killed by SIGBUS +++ Some lines above, where those errors: open("/home/pstadt/.netscape/java/download/Welcome.class", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/netscape/java/download/Welcome.class", O_RDONLY) = -1 ENOENT (No such file or directory) I made the missing directory and did another strace (nstrace02), but it always died. Then I started netscape remote on another box which has the same package-configuration and it ran!!!! (nstrace03) I did the redirection vice versa an it did, too! After all, I did another strace (nstrace04) with nearly a clean environemnt, but it died again.
When netscape is started with redirected X, the line after the connect to /var/run/.nscd_socket looks like this: connect(4, {sun_family=AF_UNIX, sun_path="/var/run/.nscd_socket"}, 110) = -1 ECONNREFUSED (Connection refused) close(4) = 0 open("/etc/nsswitch.conf", O_RDONLY) = 4 The nsswitch.conf exists on both systems, and it is worldreadable....
What's the output of chkfontpath --list on the working and non-working cases?
chkfontpath is always (on all clients) the same: (logins via X, ssh, telnet) [pstadt@becks pstadt]$ /usr/sbin/chkfontpath Current directories in font path: 1: /usr/X11R6/lib/X11/fonts/misc:unscaled 2: /usr/X11R6/lib/X11/fonts/75dpi:unscaled 3: /usr/X11R6/lib/X11/fonts/100dpi:unscaled 4: /usr/X11R6/lib/X11/fonts/misc 5: /usr/X11R6/lib/X11/fonts/Type1 6: /usr/X11R6/lib/X11/fonts/Speedo 7: /usr/X11R6/lib/X11/fonts/100dpi 8: /usr/X11R6/lib/X11/fonts/75dpi 9: /usr/share/fonts/ISO8859-2/misc 10: /usr/share/fonts/ISO8859-2/100dpi 11: /usr/share/fonts/ISO8859-2/75dpi 12: /usr/share/fonts/ISO8859-2/Type1 13: /usr/share/fonts/ISO8859-7/misc 14: /usr/share/fonts/ISO8859-7/100dpi 15: /usr/share/fonts/ISO8859-7/75dpi 16: /usr/share/fonts/ISO8859-7/Type1 17: /usr/share/fonts/ISO8859-9/100dpi 18: /usr/share/fonts/ISO8859-9/misc 19: /usr/share/fonts/ISO8859-9/75dpi 20: /usr/X11R6/lib/X11/fonts/cyrillic 21: /usr/share/fonts/default/Type1
hm, maybe it is something like a "timeout"-problem? On our "old" RH5.2-based Clients we got "Signal 13"-Errors for ssh in 9 of 10 tries after installing the ldap-Usermanagement. That was the main reason to upgrade to the "Full-LDAP-featured RH6.1" ;-)) Ok, how are our chances to get rid of this problem??? How are the RH connections to NS?? What about using a external jdk with netscape?? We now installed a work-around with a nightly generated passwd, but that is !:?#
Out of curiousity, are you running nscd? We've tried this here, and can't reproduce it.
I'm going to close this, as I was never able to reproduce it.