Bug 5992 - getpeername failure message often not informative enough
getpeername failure message often not informative enough
Status: NEW
Product: Samba 3.6
Classification: Unclassified
Component: File services
Other Linux
: P3 enhancement
: ---
Assigned To: Jeremy Allison
Samba QA Contact
Depends on:
  Show dependency treegraph
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:


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:


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 our standard file
                                   descriptors */
                                am_parent = 0;
                                /* 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.