1ACCEPT(2)                  Linux Programmer's Manual                 ACCEPT(2)
2
3
4

NAME

6       accept, accept4 - accept a connection on a socket
7

SYNOPSIS

9       #include <sys/types.h>          /* See NOTES */
10       #include <sys/socket.h>
11
12       int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
13
14       #define _GNU_SOURCE             /* See feature_test_macros(7) */
15       #include <sys/socket.h>
16
17       int accept4(int sockfd, struct sockaddr *addr,
18                   socklen_t *addrlen, int flags);
19

DESCRIPTION

21       The  accept()  system  call  is used with connection-based socket types
22       (SOCK_STREAM,  SOCK_SEQPACKET).   It  extracts  the  first   connection
23       request  on  the queue of pending connections for the listening socket,
24       sockfd, creates a new connected socket, and returns a new file descrip‐
25       tor  referring  to that socket.  The newly created socket is not in the
26       listening state.  The original socket  sockfd  is  unaffected  by  this
27       call.
28
29       The  argument  sockfd is a socket that has been created with socket(2),
30       bound to a local address with bind(2), and is listening for connections
31       after a listen(2).
32
33       The argument addr is a pointer to a sockaddr structure.  This structure
34       is filled in with the address of the peer socket, as known to the  com‐
35       munications  layer.   The  exact format of the address returned addr is
36       determined by the  socket's  address  family  (see  socket(2)  and  the
37       respective  protocol  man pages).  When addr is NULL, nothing is filled
38       in; in this case, addrlen is not used, and should also be NULL.
39
40       The addrlen argument is a value-result argument: the caller  must  ini‐
41       tialize  it  to contain the size (in bytes) of the structure pointed to
42       by addr; on return it will contain the actual size of the peer address.
43
44       The returned address is truncated if the buffer provided is too  small;
45       in  this case, addrlen will return a value greater than was supplied to
46       the call.
47
48       If no pending connections are present on the queue, and the  socket  is
49       not  marked  as nonblocking, accept() blocks the caller until a connec‐
50       tion is present.  If the socket is marked nonblocking  and  no  pending
51       connections  are  present  on  the queue, accept() fails with the error
52       EAGAIN or EWOULDBLOCK.
53
54       In order to be notified of incoming connections on a  socket,  you  can
55       use  select(2),  poll(2), or epoll(7).  A readable event will be deliv‐
56       ered when a new connection is attempted and you may then call  accept()
57       to  get  a  socket for that connection.  Alternatively, you can set the
58       socket to deliver SIGIO when activity occurs on a socket; see socket(7)
59       for details.
60
61       If  flags  is 0, then accept4() is the same as accept().  The following
62       values can be bitwise ORed in flags to obtain different behavior:
63
64       SOCK_NONBLOCK   Set the O_NONBLOCK file status flag  on  the  new  open
65                       file description.  Using this flag saves extra calls to
66                       fcntl(2) to achieve the same result.
67
68       SOCK_CLOEXEC    Set the close-on-exec (FD_CLOEXEC) flag on the new file
69                       descriptor.   See the description of the O_CLOEXEC flag
70                       in open(2) for reasons why this may be useful.
71

RETURN VALUE

73       On success, these system calls return a nonnegative integer that  is  a
74       file descriptor for the accepted socket.  On error, -1 is returned, and
75       errno is set appropriately.
76
77   Error handling
78       Linux accept() (and accept4()) passes already-pending network errors on
79       the  new  socket as an error code from accept().  This behavior differs
80       from other BSD socket  implementations.   For  reliable  operation  the
81       application  should  detect the network errors defined for the protocol
82       after accept() and treat them like EAGAIN by retrying.  In the case  of
83       TCP/IP,  these  are  ENETDOWN,  EPROTO, ENOPROTOOPT, EHOSTDOWN, ENONET,
84       EHOSTUNREACH, EOPNOTSUPP, and ENETUNREACH.
85

ERRORS

87       EAGAIN or EWOULDBLOCK
88              The socket is marked nonblocking and no connections are  present
89              to  be  accepted.   POSIX.1-2001  and  POSIX.1-2008 allow either
90              error to be returned for this case, and  do  not  require  these
91              constants  to  have  the  same  value, so a portable application
92              should check for both possibilities.
93
94       EBADF  sockfd is not an open file descriptor.
95
96       ECONNABORTED
97              A connection has been aborted.
98
99       EFAULT The addr argument is not in a writable part of the user  address
100              space.
101
102       EINTR  The  system  call  was  interrupted  by a signal that was caught
103              before a valid connection arrived; see signal(7).
104
105       EINVAL Socket is not listening for connections, or addrlen  is  invalid
106              (e.g., is negative).
107
108       EINVAL (accept4()) invalid value in flags.
109
110       EMFILE The per-process limit on the number of open file descriptors has
111              been reached.
112
113       ENFILE The system-wide limit on the total number of open files has been
114              reached.
115
116       ENOBUFS, ENOMEM
117              Not  enough free memory.  This often means that the memory allo‐
118              cation is limited by the socket buffer limits, not by the system
119              memory.
120
121       ENOTSOCK
122              The file descriptor sockfd does not refer to a socket.
123
124       EOPNOTSUPP
125              The referenced socket is not of type SOCK_STREAM.
126
127       EPROTO Protocol error.
128
129       In addition, Linux accept() may fail if:
130
131       EPERM  Firewall rules forbid connection.
132
133       In  addition,  network errors for the new socket and as defined for the
134       protocol may be returned.   Various  Linux  kernels  can  return  other
135       errors such as ENOSR, ESOCKTNOSUPPORT, EPROTONOSUPPORT, ETIMEDOUT.  The
136       value ERESTARTSYS may be seen during a trace.
137

VERSIONS

139       The accept4() system call is available starting with Linux 2.6.28; sup‐
140       port in glibc is available starting with version 2.10.
141

CONFORMING TO

143       accept():  POSIX.1-2001,  POSIX.1-2008,  SVr4,  4.4BSD  (accept() first
144       appeared in 4.2BSD).
145
146       accept4() is a nonstandard Linux extension.
147
148       On Linux, the new socket returned by accept()  does  not  inherit  file
149       status  flags such as O_NONBLOCK and O_ASYNC from the listening socket.
150       This behavior differs from the canonical  BSD  sockets  implementation.
151       Portable  programs  should not rely on inheritance or noninheritance of
152       file status flags and always explicitly set all required flags  on  the
153       socket returned from accept().
154

NOTES

156       POSIX.1-2001  does not require the inclusion of <sys/types.h>, and this
157       header file is not required on Linux.  However, some  historical  (BSD)
158       implementations  required  this  header file, and portable applications
159       are probably wise to include it.
160
161       There may not always be a connection waiting after a SIGIO is delivered
162       or  select(2),  poll(2), or epoll(7) return a readability event because
163       the connection might have been removed by an asynchronous network error
164       or another thread before accept() is called.  If this happens, then the
165       call will block waiting for the next connection to arrive.   To  ensure
166       that  accept() never blocks, the passed socket sockfd needs to have the
167       O_NONBLOCK flag set (see socket(7)).
168
169       For certain protocols which require an explicit confirmation,  such  as
170       DECnet, accept() can be thought of as merely dequeuing the next connec‐
171       tion request  and  not  implying  confirmation.   Confirmation  can  be
172       implied  by  a  normal  read  or  write on the new file descriptor, and
173       rejection can be implied by closing the new  socket.   Currently,  only
174       DECnet has these semantics on Linux.
175
176   The socklen_t type
177       In the original BSD sockets implementation (and on other older systems)
178       the third argument of accept() was declared as an  int *.   A  POSIX.1g
179       draft  standard wanted to change it into a size_t *C; later POSIX stan‐
180       dards and glibc 2.x have socklen_t * .
181

EXAMPLE

183       See bind(2).
184

SEE ALSO

186       bind(2), connect(2), listen(2), select(2), socket(2), socket(7)
187

COLOPHON

189       This page is part of release 4.15 of the Linux  man-pages  project.   A
190       description  of  the project, information about reporting bugs, and the
191       latest    version    of    this    page,    can     be     found     at
192       https://www.kernel.org/doc/man-pages/.
193
194
195
196Linux                             2016-10-08                         ACCEPT(2)
Impressum