Bug 7284

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.