1 .\" Copyright (c) 1983, 1990, 1991 The Regents of the University of California.
2 .\" All rights reserved.
4 .\" %%%LICENSE_START(BSD_4_CLAUSE_UCB)
5 .\" Redistribution and use in source and binary forms, with or without
6 .\" modification, are permitted provided that the following conditions
8 .\" 1. Redistributions of source code must retain the above copyright
9 .\" notice, this list of conditions and the following disclaimer.
10 .\" 2. Redistributions in binary form must reproduce the above copyright
11 .\" notice, this list of conditions and the following disclaimer in the
12 .\" documentation and/or other materials provided with the distribution.
13 .\" 3. All advertising materials mentioning features or use of this software
14 .\" must display the following acknowledgement:
15 .\" This product includes software developed by the University of
16 .\" California, Berkeley and its contributors.
17 .\" 4. Neither the name of the University nor the names of its contributors
18 .\" may be used to endorse or promote products derived from this software
19 .\" without specific prior written permission.
21 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
22 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
23 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
24 .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
25 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
26 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
27 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
28 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
29 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
30 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
34 .\" Modified 1993-07-24 by Rik Faith <faith@cs.unc.edu>
35 .\" Modified 1996-10-21 by Eric S. Raymond <esr@thyrsus.com>
36 .\" Modified 1998-2000 by Andi Kleen to match Linux 2.2 reality
37 .\" Modified 2002-04-23 by Roger Luethi <rl@hellgate.ch>
38 .\" Modified 2004-06-17 by Michael Kerrisk <mtk.manpages@gmail.com>
39 .\" 2008-12-04, mtk, Add documentation of accept4()
41 .TH ACCEPT 2 2021-03-22 "Linux" "Linux Programmer's Manual"
43 accept, accept4 \- accept a connection on a socket
46 .B #include <sys/socket.h>
48 .BI "int accept(int " sockfd ", struct sockaddr *restrict " addr ,
49 .BI " socklen_t *restrict " addrlen );
51 .BR "#define _GNU_SOURCE" " /* See feature_test_macros(7) */"
52 .B #include <sys/socket.h>
54 .BI "int accept4(int " sockfd ", struct sockaddr *restrict " addr ,
55 .BI " socklen_t *restrict " addrlen ", int " flags );
60 system call is used with connection-based socket types
63 It extracts the first connection request on the queue of pending
64 connections for the listening socket,
66 creates a new connected socket, and returns a new file
67 descriptor referring to that socket.
68 The newly created socket is not in the listening state.
71 is unaffected by this call.
75 is a socket that has been created with
77 bound to a local address with
79 and is listening for connections after a
87 This structure is filled in with the address of the peer socket,
88 as known to the communications layer.
89 The exact format of the address returned
91 is determined by the socket's address family (see
93 and the respective protocol man pages).
96 is NULL, nothing is filled in; in this case,
98 is not used, and should also be NULL.
102 argument is a value-result argument:
103 the caller must initialize it to contain the
104 size (in bytes) of the structure pointed to by
106 on return it will contain the actual size of the peer address.
108 The returned address is truncated if the buffer provided is too small;
111 will return a value greater than was supplied to the call.
114 connections are present on the queue, and the socket is not marked as
117 blocks the caller until a connection is present.
118 If the socket is marked
119 nonblocking and no pending connections are present on the queue,
126 In order to be notified of incoming connections on a socket, you can use
131 A readable event will be delivered when a new connection is attempted and you
134 to get a socket for that connection.
135 Alternatively, you can set the socket to deliver
137 when activity occurs on a socket; see
147 The following values can be bitwise ORed in
149 to obtain different behavior:
154 file status flag on the open file description (see
156 referred to by the new file descriptor.
157 Using this flag saves extra calls to
159 to achieve the same result.
162 Set the close-on-exec
164 flag on the new file descriptor.
165 See the description of the
169 for reasons why this may be useful.
172 these system calls return a file descriptor
173 for the accepted socket (a nonnegative integer).
174 On error, \-1 is returned,
176 is set to indicate the error, and
184 passes already-pending network errors on the new socket
185 as an error code from
187 This behavior differs from other BSD socket
189 For reliable operation the application should detect
190 the network errors defined for the protocol after
196 In the case of TCP/IP, these are
208 .BR EAGAIN " or " EWOULDBLOCK
209 .\" Actually EAGAIN on Linux
210 The socket is marked nonblocking and no connections are
211 present to be accepted.
212 POSIX.1-2001 and POSIX.1-2008
213 allow either error to be returned for this case,
214 and do not require these constants to have the same value,
215 so a portable application should check for both possibilities.
219 is not an open file descriptor.
222 A connection has been aborted.
227 argument is not in a writable part of the user address space.
230 The system call was interrupted by a signal that was caught
231 before a valid connection arrived; see
235 Socket is not listening for connections, or
237 is invalid (e.g., is negative).
245 The per-process limit on the number of open file descriptors has been reached.
248 The system-wide limit on the total number of open files has been reached.
250 .BR ENOBUFS ", " ENOMEM
251 Not enough free memory.
252 This often means that the memory allocation is limited by the socket buffer
253 limits, not by the system memory.
258 does not refer to a socket.
261 The referenced socket is not of type
272 Firewall rules forbid connection.
274 In addition, network errors for the new socket and as defined
275 for the protocol may be returned.
276 Various Linux kernels can
277 return other errors such as
279 .BR ESOCKTNOSUPPORT ,
280 .BR EPROTONOSUPPORT ,
284 may be seen during a trace.
288 system call is available starting with Linux 2.6.28;
289 support in glibc is available starting with version 2.10.
292 POSIX.1-2001, POSIX.1-2008,
295 first appeared in 4.2BSD).
296 .\" The BSD man page documents five possible error returns
297 .\" (EBADF, ENOTSOCK, EOPNOTSUPP, EWOULDBLOCK, EFAULT).
298 .\" POSIX.1-2001 documents errors
299 .\" EAGAIN, EBADF, ECONNABORTED, EINTR, EINVAL, EMFILE,
300 .\" ENFILE, ENOBUFS, ENOMEM, ENOTSOCK, EOPNOTSUPP, EPROTO, EWOULDBLOCK.
301 .\" In addition, SUSv2 documents EFAULT and ENOSR.
304 is a nonstandard Linux extension.
306 On Linux, the new socket returned by
308 does \fInot\fP inherit file status flags such as
312 from the listening socket.
313 This behavior differs from the canonical BSD sockets implementation.
314 .\" Some testing seems to show that Tru64 5.1 and HP-UX 11 also
315 .\" do not inherit file status flags -- MTK Jun 05
316 Portable programs should not rely on inheritance or noninheritance
317 of file status flags and always explicitly set all required flags on
318 the socket returned from
321 There may not always be a connection waiting after a
328 return a readability event because the connection might have been
329 removed by an asynchronous network error or another thread before
332 If this happens, then the call will block waiting for the next
333 connection to arrive.
336 never blocks, the passed socket
343 For certain protocols which require an explicit confirmation,
346 can be thought of as merely dequeuing the next connection request and not
347 implying confirmation.
348 Confirmation can be implied by
349 a normal read or write on the new file descriptor, and rejection can be
350 implied by closing the new socket.
351 Currently, only DECnet has these semantics on Linux.
353 .SS The socklen_t type
354 In the original BSD sockets implementation (and on other older systems)
355 .\" such as Linux libc4 and libc5, SunOS 4, SGI
356 the third argument of
358 was declared as an \fIint\ *\fP.
360 standard wanted to change it into a \fIsize_t\ *\fPC;
361 .\" SunOS 5 has 'size_t *'
362 later POSIX standards and glibc 2.x have