Bug 5992 - getpeername failure message often not informative enough
Summary: getpeername failure message often not informative enough
Status: NEW
Alias: None
Product: Samba 3.6
Classification: Unclassified
Component: File services (show other bugs)
Version: unspecified
Hardware: Other Linux
: P3 enhancement
Target Milestone: ---
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
URL: http://bugs.debian.org/464035
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-25 04:03 UTC by Debian samba package maintainers (PUBLIC MAILING LIST)
Modified: 2010-01-25 08:40 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Debian samba package maintainers (PUBLIC MAILING LIST) 2008-12-25 04:03:16 UTC
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.
Comment 1 Karolin Seeger 2010-01-25 08:40:17 UTC
Too late for enhancements for 3.5. Raising version.