Samba server running as a member in a NT4-controled Domain
Sometimes people trying to connect get error 64 (name not available), while people
who have an open connection still are able to access the server.
(See attachments for conf. and level 3 error log).
Server platform is SunOS 5.9 117171-17 sun4u sparc
Server does use LDAP via nsswitch/pam for UNIX authentification but samba runs
in security=Domain mode, so shouldn't care about ldap. /var/adm/messages has
samba error messages anyway.
Jun 2 16:52:00 surz32 smbd: [ID 293258 daemon.error] libsldap: Status: 9
1 Mesg: openConnection: failed to connect using TLS (Error 0)
Jun 2 16:52:00 surz32 last message repeated 3 times
Jun 2 16:52:00 surz32 smbd: [ID 293258 daemon.error] libsldap: Status: 7
Mesg: Session error no available conn.
Created attachment 1255 [details]
Created attachment 1256 [details]
please retest against 3.0.20b. I think this is probably fixed with some of the
buffer alignment issues.
We still see this problem with 3.0.20b (see below),
Turning up the log level to 10 made the problem go away, so
I cannot provide any more detailed logs.
[2005/12/02 16:23:36, 0] lib/fault.c:(37)
INTERNAL ERROR: Signal 10 in pid 7451 (3.0.20b)
Please read the Trouble-Shooting section of the Samba3-HOWTO
[2005/12/02 16:23:36, 0] lib/fault.c:(39)
[2005/12/02 16:23:36, 0] lib/fault.c:(40)
I really need a backtrace of this. Or can you tell me a
consistent way to reproduce this?
I can't produce a backtrace at the moment. However, I do have a Level-10-log from
a non-responsive samba daemon. Would that help?
Created attachment 1607 [details]
Level 10 error log
Is 3.0.22 any better? I'm not been able to reproduce this.
closing. Please reopen if the issue still exists.
(In reply to comment #8)
> Is 3.0.22 any better? I'm not been able to reproduce this.
oops. I missed that response:
I currently cannot reproduce the problem either, so closing this ticket is
ok with me.
some notes, anyway:
- binary packages were not from samba.org but from www.blastwave.org
- Upgrading to newer versions led to even more spectacular crashes (samba
daemon dying with "Illegal instruction" right upon start, tracebacks pointing
to somewhere in nss_ldap.so.
- The machines in question *do* have NSS-Problems (e.g.: "getent passwd"
produces an infinite loop), so it is not at all clear that the crashes are
- going back to the Samba2 version bundled with Solaris 9 did fix the problem