This was reported by a Debian user in the said URL. If someone looks at the full bug log, please ignore anything following the initial report, it has nothing to do with our user's real bug report ("our user" being Josip Rodin in the bug log). In short, Josip suggests to be more informative when getpeername fails. Full rationale given: Hi, source/lib/util_sock.c's get_peer_addr() function does: if (getpeername(fd, &sa, &length) < 0) { DEBUG(0,("getpeername failed. Error was %s\n", strerror(errno) )); return addr_buf; } This is littering my log.smbd file, like this: getpeername failed. Error was Transport endpoint is not connected This apparent ENOTCONN is happening a couple of times every hour on one set of my machines. At first I thought it was harmless, just logged at the level 0 (always), but looking more into the source, this should be getting generated after the following sequence of call in source/smbd/server.c: if (allowable_number_of_smbd_processes() && smbd_server_fd() != -1 && sys_fork()==0) { /* Child code ... */ /* close the listening socket(s) */ for(i = 0; i < num_sockets; i++) close(fd_listenset[i]); /* close our standard file descriptors */ close_low_fds(False); am_parent = 0; set_socket_options(smbd_server_fd(),"SO_KEEPALIVE"); set_socket_options(smbd_server_fd(),user_socket_options); /* this is needed so that we get decent entries in smbstatus for port 445 connects */ set_remote_machine_name(get_peer_addr(smbd_server_fd()), False); ... Perhaps it would be a good idea to test if smbd_server_fd() is returning something which is dead there, because something else could be going wrong... and I'd like to be able to know more about what is causing these.
Too late for enhancements for 3.5. Raising version.