Bug 2765 - Samba server stops responding, restarting demons helps, spurious(?) ldap error messages
Samba server stops responding, restarting demons helps, spurious(?) ldap erro...
Status: RESOLVED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.20b
Sparc Solaris
: P3 normal
: none
Assigned To: Gerald (Jerry) Carter
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-02 07:59 UTC by Wolfgang Ratzka
Modified: 2006-04-18 03:46 UTC (History)
0 users

See Also:


Attachments
Error log (43.61 KB, text/plain)
2005-06-02 08:11 UTC, Wolfgang Ratzka
no flags Details
testparm output (989 bytes, text/plain)
2005-06-02 08:12 UTC, Wolfgang Ratzka
no flags Details
Level 10 error log (659.43 KB, text/plain)
2005-12-09 02:49 UTC, Wolfgang Ratzka
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wolfgang Ratzka 2005-06-02 07:59:40 UTC
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[16839]: [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[16839]: [ID 293258 daemon.error] libsldap: Status: 7
  Mesg: Session error no available conn.
Comment 1 Wolfgang Ratzka 2005-06-02 08:11:58 UTC
Created attachment 1255 [details]
Error log
Comment 2 Wolfgang Ratzka 2005-06-02 08:12:27 UTC
Created attachment 1256 [details]
testparm output
Comment 3 Gerald (Jerry) Carter 2005-10-12 09:56:01 UTC
please retest against 3.0.20b.  I think this is probably fixed with some of the
buffer alignment issues.
Comment 4 Wolfgang Ratzka 2005-12-02 09:03:32 UTC
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)
  
  From: http://www.samba.org/samba/docs/Samba3-HOWTO.pdf
[2005/12/02 16:23:36, 0] lib/fault.c:(40)
  ===============================================================
Comment 5 Gerald (Jerry) Carter 2005-12-02 09:15:27 UTC
I really need a backtrace of this.  Or can you tell me a
consistent way to reproduce this?
Comment 6 Wolfgang Ratzka 2005-12-05 09:41:28 UTC
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?
Comment 7 Wolfgang Ratzka 2005-12-09 02:49:33 UTC
Created attachment 1607 [details]
Level 10 error log
Comment 8 Gerald (Jerry) Carter 2006-04-08 22:59:08 UTC
Is 3.0.22 any better?  I'm not been able to reproduce this.
Comment 9 Gerald (Jerry) Carter 2006-04-14 14:47:08 UTC
closing.  Please reopen if the issue still exists.
Comment 10 Wolfgang Ratzka 2006-04-18 03:46:47 UTC
(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
  samba problems
- going back to the Samba2 version bundled with Solaris 9 did fix the problem
  for now.