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  open  file
65                       description  (see  open(2)) referred to by the new file
66                       descriptor.  Using  this  flag  saves  extra  calls  to
67                       fcntl(2) to achieve the same result.
68
69       SOCK_CLOEXEC    Set the close-on-exec (FD_CLOEXEC) flag on the new file
70                       descriptor.  See the description of the O_CLOEXEC  flag
71                       in open(2) for reasons why this may be useful.
72

RETURN VALUE

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

ERRORS

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

VERSIONS

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

CONFORMING TO

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

NOTES

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

EXAMPLE

184       See bind(2).
185

SEE ALSO

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

COLOPHON

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