Bug 7284
Summary: | netscape-JAVA and LDAP | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Oliver Paukstadt <pstadt> |
Component: | netscape | Assignee: | Bill Nottingham <notting> |
Status: | CLOSED WORKSFORME | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 6.1 | CC: | rvokal |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 1999-12-20 22:02:16 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Oliver Paukstadt
1999-11-24 12:45:13 UTC
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. |