Every 6 minutes ... broken pipe

Neil Hoggarth neil.hoggarth at physiol.ox.ac.uk
Mon Mar 26 08:49:37 GMT 2001


On Mon, 26 Mar 2001, Andrew Tridgell wrote:

> The keepalives to the password server are essential because without
> them the server will drop the idle connection. There is no way to
> re-establish them due to the braindead design of SMB. The crypt-key
> cannot be re-negotiated and is chosen by the server, so if any new
> session setup calls come from clients after the password server
> connection is gone then all you can do is fail them. That's bad.

Objection, m'lud: the password server connection idles out anyway! That
is *why* the broken pipe messages occur every time the timeout
processing is done (note I only have experience of the case where the
password server is a Samba server - presumably if one uses an NT machine
as a password server then the keepalives actually keep the connection
alive?).

Why do we need the password server connection nailed up? Surely once the
user has been authenticated it isn't going to be needed again? I set
global keepalives=0 on my Samba servers six or seven months ago, just
clear the logs of these messages, and I haven't seen any problems.

One thought though: I use inetd to run my daemons - does smbd run parent
daemon mode use a single authentication connection, or is there still a
seperate authentication connection for each child smbd?

> Use security=domain (that solves the problem) or alternatively we
> could keep a pipe open on the password server to keep it occupied.

Incidently, I've been meaning to investigate this, but not got around to
it: does security=domain work with a Samba PDC? (bearing in mind that
all us well behaved people are still running 2.0.7 on our production
servers :-)).

Regards,
-- 
Neil Hoggarth                                 Departmental Computer Officer
<neil.hoggarth at physiol.ox.ac.uk>                   Laboratory of Physiology
http://www.physiol.ox.ac.uk/~njh/                  University of Oxford, UK







More information about the samba-technical mailing list