David.Collier-Brown at canada.sun.com
Thu Nov 2 13:25:55 GMT 2000
Nagy Tamás wrote:
> I've noticed that when the inner network is slightly loaded, the
> farther on (the) linux, couldn't enter the network. It's because (the)
> doesn't allow them to enter.
> In that case when (the) linux didn't allow me to enter, in the log
> file I
> found things like that:
> [2000/10/31 11:17:31, 0] lib/util_sock.c:write_socket_data(537)
> write_socket_data: write failure. Error = Broken pipe
> [2000/10/31 11:17:31, 0] lib/util_sock.c:write_socket(563)
> write_socket: Error writing 4 bytes to socket 11: ERRNO = Broken
> [2000/10/31 11:17:31, 0] lib/util_sock.c:send_smb(751)
> Error writing 4 bytes to client. -1. Exiting
You actually should have asked this question in the
samba at samba.org mailing list: samba-technical is about
developing new versions of Samba.
However, you're seeing the client disconnct for some
reason: the problem is finding out the reason so the
team can fix the $#^!&*!!### thing.
I'm attaching a note on diagnosing it: anyone want to
add to or improve it, oh real experts?
David Collier-Brown, | Always do right. This will gratify some people
185 Ellerslie Ave., | and astonish the rest. -- Mark Twain
Willowdale, Ontario | //www.oreilly.com/catalog/samba/author.html
Work: (905) 415-2849 Home: (416) 223-8968 Email: davecb at canada.sun.com
-------------- next part --------------
Diagnosing "Broken Pipe" errors.
Every so often these days (circa win98, win2k), we see error messages
like the following showing up in the logs:
[2000/09/08 18:06:24, 0]
write_socket_data: write failure. Error = Broken pipe
[2000/10/05 11:08:16, 0] lib/util_sock.c:read_socket_data(477)
read_socket_data: recv failure for 1252. Error = Connection reset
These are unexpected client disconnections, as seen by Samba.
Interestingly, they can also cause the client to report "The network is
busy" while trying to (re-)map the file.
If you happen to be using security = server, the Samba messages
can be eliminated by setting keepalive = 0. If you are using any
other security setting, use keepalive = 30 to tell Samba to
clean up more often (this won't reduce the messages, though!)
They usually indicates an error by the client, which caused
1) blue screen
3) silently disconect and reconnect.
The latter is the annoying one...
The usual cause is a networking problem. What the team's seen
a lot lately are bad drivers for ethernet cards (especially on
Windows ME) or mismatches between ethernet cards and hubs.
Both ends of each connection between a hub and a machine must
be running at the same speed, either 10 or 100 Mbit/S and at the
same duplex setting (half- or full-duplex, sometimes called simplex
A mismatch is usually detectable using ftp: if copying in one
direction is an order of magnitude fast than the other, you have
a problem. Note that being a little slower one way than the other
is normal: my machine at work looks like this:
ftp> get gnuplot-3.7-sol8-sparc-local foo
200 PORT command successful.
150 ASCII data connection for gnuplot-3.7-sol8-sparc-local (22.214.171.124,39390) (1159384
226 ASCII Transfer complete.
local: foo remote: gnuplot-3.7-sol8-sparc-local
1163024 bytes received in 1.2 seconds (955.88 Kbytes/s)
ftp> put foo foo
200 PORT command successful.
150 ASCII data connection for foo (126.96.36.199,39394).
226 Transfer complete.
local: foo remote: foo
1163024 bytes sent in 0.45 seconds (2520.48 Kbytes/s)
So the "get" is 37% of the "put" speed (the put is writing to a
slower disk than the get was).
Looking at ethernet stats can help, too: netstat -i output
should look something like:
Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue
lo0 8232 loopback localhost 1904006 0 1904006 0 0 0
hme0 1500 elsbeth elsbeth 8278338 1 2280982 0 579602 0
The number of errors should be **very** low: I have about
1 in 12,100,000.
The number of collisions should be below 3% UNLESS you have
a cut-through (first generation) ethernet hub. I have 25.4%
because I have a cut-through hub on this machine.
The failing client can be found by using smbstatus repertedly.
Look at the "pid" column:
Samba version 2.0.7
Service uid gid pid machine
temp davecb staff 18310 elsbeth (188.8.131.52) Tue Sep 12 07:49:40 2000
If elsbeth had been failing and reconnecting, a previous
smbstatus would have looked the same, but the pid would be
different, as Samba starts a new process on each (re-)connection.
More information about the samba-technical