shutdown(2) System Calls Manual shutdown(2)
shutdown() - shut down a socket
The system call is used to shut down a socket. In the case of a full-duplex connection, can be used to either partially or fully shut down
the socket, depending upon the value of how.
Further receives are disallowed
Further sends are disallowed
Further sends and receives are disallowed
The s parameter is a socket descriptor for the socket to be shut down.
Once the socket has been shut down for receives, all further calls return an end-of-file condition. A socket that has been shut down for
sending causes further calls to return an error and send the signal. After a socket has been fully shut down, operations other than and
return appropriate errors, and the only other thing that can be done to the socket is a
Multiple shutdowns on a connected socket and shutdowns on a socket that is not connected may not return errors.
A on a connectionless socket, such as only marks the socket as unable to do further or calls, depending upon the value of how. Once this
type of socket has been disabled for both sending and receiving data, it becomes fully shut down. For sockets, if how is or the connection
begins to be closed gracefully in addition to the normal actions. However, the call does not wait for the completion of the graceful dis-
connection. The disconnection is complete when both sides of the connection have done a with how equal to or Once the connection has been
completely terminated, the socket becomes fully shut down. The option (see socket(2)) does not have any meaning for the call, but does for
the call. For more information on how the call interacts with sockets, see socket(2).
If a is performed on a socket that has a pending on it, that socket becomes fully shut down when how
The how parameter behaves differently if the socket is of the address family. If how is set to the specified socket can no longer receive
data. The SVC is not cleared and remains intact. However, if data is subsequently received on the SVC, it is cleared. The connection is
not completely down until either side executes a or with how set to or
If how is set to or the SVC can no longer send or receive data and the SVC is cleared. The socket's resources are maintained so that data
arriving prior to the call can still be read.
SCTP differs from TCP in that SCTP does not have half closed semantics. Hence the call for SCTP is an approximation of the TCP call and
solves some different problems. Full TCP-compatibility is not provided, so developers porting TCP applications to SCTP may need to re-code
sections that use You can achieve the same results as half closed semantics in SCTP by using SCTP streams.
These are the possible SCTP operations:
Disables further receive operations.
No SCTP protocol action is taken.
Disables further send operations and initiates the SCTP shutdown
Disables further send and receive operations and initiates the
SCTP shutdown sequence.
The major difference between SCTP and TCP is that SCTP initiates immediate and full protocol shutdown, whereas TCP causes TCP to go into
the half closed state. behaves the same for SCTP as TCP. The purpose of SCTP is to close the SCTP association while still leaving the
socket descriptor open, so that the caller can receive back any data SCTP was unable to deliver.
Note: SCTP is only available when the SCTP optional bundle is installed.
X/Open Sockets Compilation Environment
Upon successful completion, returns 0; otherwise it returns -1 and is set to indicate the error.
fails if any of the following conditions are encountered:
s is not a valid file descriptor.
The remote system or an intermediate system in the communications path
does not support a protocol option sent by the local system. This option may have been set using a or call, or set
as a system parameter.
s is a valid file descriptor, but it is not a socket.
The specified socket is not connected.
The specified socket is not connected.
The how argument is invalid.
Linking binary objects compiled to specification and binary objects compiled to specification to the same executable may result in unex-
pected behavior, including application abnormal termination and unexpected socket errors. See xopen_networking(7) for details and remedy.
Currently, the default behavior is the however, it might be changed to in a future release. At that time, any behavior that is incompati-
ble with might be obsoleted. Applications that conform to the X/Open specification now will avoid migration problems (see xopen_network-
was developed by HP and the University of California, Berkeley.
close(2), connect(2), socket(2), sctp(7), xopen_networking(7).