intro(2) DG/UX R4.11MU05 intro(2)
NAME
intro - introduction to DG/UX system calls and error numbers
SYNOPSIS
#include <errno.h>
DESCRIPTION
This man page is an introduction to the DG/UX system calls. It
contains two major headings: DEFINITIONS and DIAGNOSTICS.
The DEFINITIONS section identifies important system abstractions and
describes them briefly in terms of their representation in the system
(for example, the process id abstraction is described in terms of its
identity within the system, a positive integer used to identify a
process). The definitions are grouped into the following categories:
Files, Processes, Sockets, and System V Interprocess Communications
Mechanisms. The System V IPC Mechanisms section covers message
queues, shared memory segments, and semaphores, and the Sockets
section describes the DG/UX Socket facilities, which are based on the
Berkeley UNIX IPC facilities. Though sockets and System V IPC
objects are all part of interprocess communications, we have chosen
to separate them because they are handled in a completely different
manner in the DG/UX system.
This man page does not include definitions that are specific to DG/UX
systems with an added information security option (ISO). Though the
definitions hold for all DG/UX systems, additional restrictions may
apply in the case of a system with an added ISO. See security(5) for
a description of these restrictions.
Most of the definitions are short and do not suggest the programming
contexts in which the system calls are used; they generally refer the
reader to one or more individual system call descriptions in the
manual. The Sockets section is an exception. It is a rather
extensive discussion, based on the 4.2BSD System Manual by Joy,
Cooper, Fabry, Leffler, McKusick, and Mosher, University of
California, Berkeley, Berkeley CA.
The DIAGNOSTICS section is a comprehensive listing of error
conditions by name and description. At the end of the DIAGNOSTICS
section is a discussion of implementation-dependent constants that
are referenced in the discussions of individual calls.
DEFINITIONS
Files
Current Working Directory
The directory relative to which a process resolves relative
pathnames. (See Pathname.)
Descriptor
An integer assigned by the system to a file or a socket. The
descriptor uniquely identifies an access path to the associated file
or socket from a given process or any of its children. It is
assigned to a file by a call to creat(2), open(2), dup(2), fcntl(2),
or pipe(2), or to a socket by a call to socket(2) or socketpair(2).
The assignment is terminated by a call to close(2).
A process may have no more than OPEN_MAX descriptors (0 to
(OPEN_MAX-1)) open simultaneously, unless the RLIMIT_NOFILE command
of setrlimit(2) has been used to increase the limit.
The descriptor is used as an argument in calls to routines such as
read(2), write(2), ioctl(2), send(2), recv(2), and close(2).
It is known as the file descriptor in System V.
Directory
A file containing links, where links associate objects with files.
By convention, a directory contains at least two links, . and ..,
referred to as dot and dot-dot, respectively. Dot identifies the
directory itself, and dot-dot identifies its parent directory, the
directory that contains a link to the current directory. Each
directory in a file hierarchy has exactly one parent directory.
File Access Permissions
A set of flags associated with a file in the file system, which is
the basis for file access control on a standard DG/UX system and
discretionary access control (DAC) on a system with added information
security options. (See security(5).)
Standard DG/UX file access control either grants or denies a process
permission to perform a file operation (e.g., file write) based on
the file's permission flags. This is done as follows.
The system initiates an access check by determining the process'
permission class. A file has three permission classes on a standard
DG/UX system: owner, group, and other. The permission class of the
requesting process depends upon the process' relationship to the
file, which may be effective owner, effective group owner or other.
The system then determines which access flags apply to the process
for the given operation. Usually, there are three access flags for
each class: read (r), write (w), and execute (x). The exception is
IPC Objects, which have only two flags (read and write) for each
permission class.
The access flags that the system checks depends upon the operation
requested. For example, if a process that is an effective group
owner but not an effective owner tries to open a file for reading,
the system checks the read access flag in the group permission class.
Multiple access flags may be checked for some operations; for
example, to use the ls(1) command to list the contents of a
directory, the effective user must have read and execute permission
in that directory.
The system gives final authority in file access decisions to the
permission flags themselves. Thus, it grants a process permission to
perform a file operation only if the appropriate access flags in the
appropriate class within the file's mode are "on".
File access permissions can be overridden by a process with
appropriate privilege. (See appropriateprivilege(5) and
security(5).)
A file's access permissions are set when the file is created. In a
standard DG/UX system, they can be masked upon creation if umask(2)
is in effect, and they can be changed explicitly with chmod(2) or
chgrp(2).
See security(5) for an explanation of how file access permissions are
used in DAC.
Filename
A null-terminated string no longer than NAMEMAX characters long that
identifies an ordinary file, special file, or directory.
The filenames . and .. have special meaning. (See Pathname.)
The characters in a filename may have any value, except for (null)
and / (slash).
Avoid using *, ?, @, #, $, ^, &, ', (, ), `, |, ;, ", <, >, [, \, ],
!, ~ { or } as part of filenames, since some shells attach special
meaning to them. Avoid using - as the first character of a filename,
since - is commonly used to begin an option in a command line. Also,
avoid using unprintable characters in filenames. See sh(1) and
csh(1).
Pathname
A null-terminated string no longer than MAXPATH characters long that
identifies a file. It consists of an optional slash (/), followed by
zero or more filenames separated by slashes, and one or more optional
trailing slashes (in the case of a directory).
A pathname that begins with a slash is called an absolute pathname,
and specifies that the path search should begin at the root directory
of the process. Any other pathname is referred to as a relative
pathname, and specifies that the search should begin from the current
working directory. Unless specifically stated otherwise, the null
pathname is treated as if it named a non-existent file.
The system begins the path search by determining the identity of the
first file in the pathname (the current working directory or root
directory for a process), which is the starting directory for the
search. If the starting directory is located successfully, and if
the path name contains a second filename, the system looks for the
second file in the starting directory. If the second file is located
successfully, and if the pathname contains a third file, the system
assumes that the second file was a directory, and looks for the third
file in that directory. The search continues in this way, with the
system looking for each file it retrieves from the pathname in the
directory specified by its predecessor. The search terminates when
the system exhausts the pathname, or when it fails to locate one of
the files, in which case the search ends in failure. The pathname is
exhausted either when the system retrieves the last filename
specified in the path, or when it finishes processing the first
NAMEMAX characters of the pathname.
Root Directory
The directory relative to which a process resolves absolute
pathnames. (See Pathname.)
The root directory of a process can be changed by a call to
chroot(2).
Processes
Group ID
A non-negative integer used to identify a group of system users.
Each user belongs to at least one group, where each group is
identified by a group ID. Associated with each active process are at
least two group IDs, referred to as the real group ID and the
effective group ID. In addition, a process may have up to
NGROUPSMAX supplementary group IDs. By default, the real group ID
is equal to the group ID of the user who created the process, and the
supplementary group IDs are equal to the supplementary group IDs of
the parent process at the time of creation, unless the process or one
of its ancestors evolved from a file that had the set-user-ID bit or
set-group-ID bit set; see exec(2). The real group ID and the
supplementary group IDs are all subject to change while the process
remains active.
Parent Process ID
The process ID the process that created the current process; see
fork(2).
Process Group ID
A positive integer identifying the process group to which an active
process belongs. This ID is the process ID of the group leader.
This grouping permits the signaling of related processes; see
kill(2).
Process Group Leader
A process that creates a new process group. The process group ID of
a process group is equal to the process group ID of the process group
leader.
Process ID
A positive integer that uniquely identifies an active process.
Process IDs range from 0 to PID_MAX. When a process terminates or
otherwise becomes inactive, the system dissociates it from its
process ID, making the ID available for future processes.
Special Process
A process with a process ID of 0 or 1, referred to as proc0 or proc1.
Proc0 is the scheduler, and proc1 is the initialization process
(init). Proc1 is the ultimate ancestor of every other process in the
system; it controls the process structure.
Tty Group ID
A positive integer that identifies the terminal group of an active
process, when that process belongs to a terminal group. The tty
group ID can be used to terminate a group of related processes when
one of the processes in the group is terminated; see exit(2) and
signal(2).
User ID
A non-negative integer used to identify a system user. Associated
with each active process are at least two user IDs, referred to as
the real user ID and the effective user ID. By default, the real
user ID identifies the user who created the process, unless the
process or one of its ancestors evolved from a file that had the set-
user-ID bit or set-group-ID bit set; see exec(2). However, the
effective user id is subject to change while the process remains
active.
Sockets
Communications Domain
The hardware over which socket communications are to take place. The
system provides access to an extensible set of communication domains,
each of which is identified by a manifest constant defined in the
file <sys/socket.h>. Important standard domains supported by the
system are the UNIX domain (AF_UNIX) for communication within the
system and the INTERNET domain (AF_INET) for communication in the
DARPA Internet. Other domains can be added to the system.
Socket
One of the two endpoints for communications within a given domain.
Associated with each socket are send and receive queues which the
socket can use to exchange data with other sockets within its domain.
Sockets are typed according to their communications properties, e.g.
whether messages sent and received by the socket require the name of
the partner, whether communication is reliable, what format is used
in naming message recipients, and whether duplication is prevented.
The types of sockets supported are characteristic of the kernel;
consult socket(2) for more information socket types and their
properties. The basic set of socket types is defined in
<sys/socket.h>:
#define SOCKDGRAM 1 /* datagram */
#define SOCKSTREAM 2 /* virtual circuit */
#define SOCKRAW 3 /* raw socket */
#define SOCKRDM 4 /* reliably-delivered message */
#define SOCKSEQPACKET 5 /* sequenced packets */
The SOCK_DGRAM type models the semantics of datagrams in network
communication: messages may be lost or duplicated and may arrive out-
of-order. The SOCK_RDM type models the semantics of reliable
datagrams: messages arrive unduplicated and in order, and the sender
is notified if messages are lost. The send and receive operations
(described below) generate reliable/unreliable datagrams. The
SOCK_STREAM type models connection-based virtual circuits: two-way
byte streams with no record boundaries. The SOCK_SEQPACKET type
models a connection-based, full-duplex, reliable, sequenced packet
exchange; the sender is notified if messages are lost, and messages
are never duplicated or presented out of order. Users of the last
two abstractions may use the facilities for out-of-band transmission
to send out-of-band data. SOCK_RAW is used for unprocessed access to
internal network layers and interfaces; it has no specific semantics.
Other socket types can be defined.
NOTE: The DG/UX system does not support the SOCK_RDM and
SOCK_SEQPACKET types.
Socket Protocol
The protocol governing communications between sockets of a given type
in a given communications domain.
For each type of socket there is a protocol, which is used within the
domain to implement the semantics used for that socket type. For
example, within the INTERNET domain, the SOCK_DGRAM type may be
implemented by the user datagram protocol (UDP), and the SOCK_STREAM
type may be implemented by the transmission control protocol (TCP),
while no standard protocols to provide SOCK_RDM or SOCK_SEQPACKET
sockets exist.
Each kernel supports some number of sets of communications protocols.
Each protocol set supports addresses of a certain format. An address
family is the set of addresses for a specific group of protocols.
Each socket has an address chosen from the address family in which
the socket was created.
Socket Creation
The establishment of an unconnected socket (that is, a socket that
had not been paired with a peer socket for communications purposes)
through a call to socket(2):
int s; s = socket(domain, type, protocol);
int domain, type, protocol;
The descriptor s can be used to establish a connected socket in one
of two ways: by naming the socket and waiting for another socket to
request a connection with it, or by requesting a connection with an
already named socket.
Socket Naming
The process of associating an unconnected socket with a name in the
communications domain, a necessary step in converting it to a
connected socket. This association can be established explicitly by
a call to bind(2):
bind(s, name, namelen);
int s; char *name; int namelen;
A socket's bound name may be retrieved with a call to getsockname(2):
getsockname(s, name, namelen);
int s; result caddrt name; result int *namelen;
while the peer's name can be retrieved with getpeername(2):
getpeername(s, name, namelen);
int s; result caddrt name; result int *namelen;
Some domains support sockets with multiple names.
Listening for Connections
The establishment of a "wait state", in which a named, unconnected
socket waits for connection requests from other sockets. This is
effected by a call to listen(2):
listen(s, backlog);
int s, backlog;
The backlog parameter specifies the maximum number of pending
connection requests allowed in the wait queue.
Accepting Connections
The process of establishing an active connection between a named
socket and a socket that has entered a connection request in the wait
queue. (See Listening for Connections.) This is done through a call
to accept(2), which returns a descriptor s for a new, connected
socket from the queue of pending connections:
t = accept(s, name, anamelen);
result int t; int s; result caddrt name; result int
*anamelen;
Requesting Connections
The act of requesting an active connection with a named socket
through a call to connect(2):
connect(s, name, namelen);
int s; caddrt name, int namelen;
The Socketpair Shortcut
An alternative to the use of named sockets to establish socket
connections, in which descriptors for an already connected pair of
sockets is obtained through a call to socketpair(2):
socketpair(d, type, protocol, sv);
int d, type, protocol; result int sv[2];
(only in the "unix" communication domain): Here, the descriptors sv
correspond to those obtained via accept(2) and connect(2).
Socket Messaging
The process of sending and receiving messages via connected or
unconnected sockets. Messages may be sent from a socket by calling
sendto(2), if the socket is not connected:
cc = sendto(s, buf, len, flags, to, tolen);
result int cc; int s; caddrt buf; int len, flags; caddrt to;
int tolen;
or send(2), if the socket is connected:
cc = send(s, buf, len, flags);
result int cc; int s; caddrt buf; int len, flags;
The corresponding receive primitives are recvfrom(2) and recv(2):
msglen = recvfrom(s, buf, len, flags, from, fromlenaddr);
result int msglen; int s; result caddrt buf; int len, flags;
result caddrt from; result int *fromlenaddr;
msglen = recv(s, buf, len, flags);
result in msglen; int s; result caddrt buf; int len, flags;
In the unconnected case, to and tolen specify the destination or
source of the message, from stores the source of the message, and
fromlenaddr is used to specify the size of the from buffer to the
function and to store the true length of the from address after the
function call.
All calls use the message buffer of length len bytes, starting at
address buf, to store or retrieve the message to be processed. The
flags parameter is used for special purposes, such as peeking at a
message without reading it, or sending/receiving high-priority out-
of-band messages, as follows:
#define MSGPEEK 0x1 /* peek at incoming message */
#define MSGOOB 0x2 /* process out-of-band data */
An alternative to calling send(2) and recv(2) explicitly is to use
the standard DG/UX read(2) and write(2) functions, which the system
translates into send(2) and recv(2). The read(2) and write(2)
functions can operate on a virtual circuit socket, a terminal or a
file with blocking or non-blocking input/output operations without
knowing the descriptor type.
Scattering/Gathering Data and Exchanging Access Rights
The process of transmitting or receiving data or access rights
through a call to sendmsg(2) or recvmsg(2).
The sendmsg(2) and recvmsg(2) functions are as follows:
sendmsg(s, msg, flags);
int s; struct msghdr *msg; int flags;
msglen = recvmsg(s, msg, flags);
result in msglen; int s; result struct msghdr *msg;
int flags;
Both of these functions require a large number of parameters, which
are passed in the message header structure msghdr (<sys/socket.h>):
struct msghdr {
caddrt msgname; /* optional address */
int msgnamelen; /* size of address */
struct iov *msgiov; /* scatter/gather array */
int msgiovlen; /* #elements in msgiov */
caddrt msgaccrights; /* access rights sent/received */
int msgaccrightslen;/* size of msgaccrights */
};
msgname and msgnamelen specify the source or destination address if
the socket is unconnected; msgname may be a null pointer if no names
are desired or required. msgiov and msgiovlen describe the
scatter/gather locations.
Shutting Down Halves of Full-duplex Connections
The act of shutting down a full-duplex socket, such as a virtual
circuit, when that socket is no longer needed for communications
purposes. This is done through a call to shutdown(2):
shutdown(s, direction);
int s, direction;
where s is the socket descriptor, and direction specifies the
direction of the shutdown, as follows: 0 to not read further, 1 to
not write further, or 2 to completely shut the connection down.
Socket and Protocol Options
User-controllable parameters that specify implementation-specific or
non-standard socket settings. These options may be retrieved and
controlled via calls to getsockopt(2) and setsockopt(2):
getsockopt(s, level, optname, optval, optlen)
int s, level, optname; result caddrt optval;
result int *optlen;
setsockopt(s, level, optname, optval, optlen)
int s, level, optname; caddrt optval; int optlen;
The option optname is interpreted at the indicated protocol level for
socket s. If a value is specified with optval and optlen, it is
interpreted by the software operating at the specified level. The
level SOL_SOCKET indicates options maintained by the socket
facilities. Other level values indicate a particular protocol that
is to act on the option request; these values are normally
interpreted as a "protocol number".
UNIX Communications Domain
This section describes briefly the properties of the UNIX
communications domain.
The UNIX domain supports two socket types: SOCK_STREAM, which
provides pipe-like facilities, and SOCK_DGRAM, which provides
reliable message-style communications.
Socket names are strings and appear in the UNIX file system name
space. (The DG/UX implementation of the UNIX domain embeds bound
sockets in the UNIX file system name space; this is a side effect of
the implementation.)
INTERNET Communications Domain
This section describes briefly how the INTERNET domain is mapped to
the model described in this section.
The INTERNET domain supports the SOCK_STREAM socket type with the
INTERNET TCP protocol, and the SOCK_DGRAM type with the UDP protocol.
The SOCK_SEQPACKET has no direct INTERNET family analogue; a protocol
layered on top of IP could be implemented to fill this gap.
A socket name in the INTERNET consists of a 32-bit internet address
and a 16-bit port number. Options may be used to provide source
routing for the address, security options, or additional addresses
for subnets of INTERNET for which the basic 32-bit addresses are
insufficient.
No access rights transmission facilities are provided in the INTERNET
domain.
On a generic DG/UX system, the INTERNET domain allows a user with
appropriate privilege to access the raw facilities of the network
interfaces and the internal layers of the protocol implementation for
purposes of system administration and debugging. These interfaces
are modeled as SOCK_RAW sockets.
System V Interprocess Communications Mechanisms
Object Access Permissions
A set of flags associated with an IPC object, which is the basis for
IPC object access control on a standard DG/UX system and DAC on a
system with an added information security option. (See security(5)
and File Access Permissions.)
The permission flags are stored in an ipcperm structure (/sys/ipc.h)
associated with each message queue, shared memory segment or
semaphore. This structure has the following main fields:
uidt cuid;
gidt cgid;
uidt uid;
gidt gid;
unsigned long mode;
cuid is the effective user ID of the creating process. cgid is the
effective group ID of the creating process. uid is the user ID of
the current owner of the IPC object. gid is the group ID of the
current owner of the IPC object. mode is the IPC object's access
permission flags.
The permission flags can be extracted from the mode field as follows:
00400 Read by user
00200 Write by user
00040 Read by group
00020 Write by group
00004 Read by other
00002 Write by other
Message Queue
A FIFO data structure used to pass data between processes. The
maximum number of message queues allowed is configurable, with a
value determined by the SCMAXMSGSZ configuration parameter, which
can be obtained through a call to sysconf(2).
Message Queue Identifier
A positive integer used by a system to uniquely identify a message
queue. A message queue identifier (msqid) is created by a msgget(2)
system call. Associated with each msqid are a message queue and a
msqidds data structure, whose main fields are as follows:
struct ipcperm msgperm;
ushort msgqnum;
ushort msgqbytes;
pidt msglspid;
pidt msglrpid;
timet msgstime;
timet msgrtime;
timet msgctime;
msgperm is an ipcperm structure that specifies the message's
operation permissions (See Object Access Permissions). msgqnum is
the number of messages currently on the queue. msgqbytes is the
maximum number of bytes allowed on the queue. msglspid and
msgstime are the process ID and invocation time of the last process
that performed a msgsnd operation. msglrpid and msgrtime are the
process ID and invocation time of the last process that performed a
msgrcv(2) operation. msgctime is the creation time of the msgid, or
the invocation time of the last msgctl(2) operation that changed a
member of the msgperm structure.
Semaphore
A data structure used to control the sharing of a resource among
multiple processes. The maximum number of semaphores is
configurable, with a value determined by the cfpsmaxsemaphoresets
kernel configuration parameter.
Semaphore Identifier
A positive integer (semid) returned by a semget(2) system call, which
uniquely identifies a semaphore set. Associated with each semid is a
set of semaphores and a semidds data structure with the following
major fields:
struct ipcperm semperm;
ushort semnsems;
timet semotime;
timet semctime;
Semperm is an ipcperm structure that specifies the semaphore
operation permissions (See Object Access Permission). semnsems is
the number of semaphores in the set, where each semaphore in the set
is referenced by a positive integer semnum between 0 and
sem_nsems-1. Semotime is the time of the last semop(2) operation.
semctime is the creation time of the semid or the invocation time of
the last semctl(2) operation that changed a member of the semperm
structure.
Shared Memory Segment
An address range that may be mapped into the address spaces of
multiple processes simultaneously, thus allowing sharing of its
contents. The maximum number of shared memory segments is
configurable, with a value determined by the
cfpsmaxnumbersegments kernel configuration parameter.
Shared Memory Identifier
A positive integer (shmid) returned by a shmget(2) system call, which
uniquely identifies a shared memory segment. Associated with each
shmid is a shared memory segment and a shmidds data structure with
the following major fields:
struct ipcperm shmperm;
int shmsegsz;
pidt shmcpid;
pidt shmlpid;
ushort shmnattch;
timet shmatime;
timet shmdtime;
timet shmctime;
Shmperm is an ipcperm structure that specifies the shared memory
operation permissions (See Object Access Permissions). Shmsegsz is
the size, in bytes, of the shared memory segment. Shmcpid is the
process ID of the process that created the shmid. Shmlpid is the
process ID of the last process that performed a shmat(2) or shmdt(2)
operation. Shmnattch is the number of processes with this segment
currently attached. Shmatime is the time of the last shmat(2)
operation. shmdtime is the time of the last shmdt(2) operation.
shmctime is the creation time of the shmid or the invocation time of
the last shmctl(2) operation that changed a member of the shmperm
structure.
DIAGNOSTICS
Most system calls have one or more error returns. An error condition
is generally indicated by an otherwise impossible returned value.
This value is almost always -1; the individual descriptions specify
the details of each error. When an error occurs, an error number is
recorded and made available in the external variable errno. Errno is
not cleared on successful calls, so it should be tested only after an
error has been indicated.
Each system call description in this manual lists the possible error
numbers that the call supports. The descriptions listed in the
individual sections may not be identical to the ones listed here;
they try to be specific to the particular call's context. The
following is a complete general reference list of all error numbers
and their names as they are defined in <errno.h>.
Numbering
EPERM Not owner
A process attempted to do something forbidden, such as to
modify a file in some way forbidden to all except the file's
owner or a user with appropriate privilege.
ENOENT No such file or directory
The system encountered a pathname that was too long,
references to a nonexistent file, or a pathname that specified
an invalid directory (e.g., a nonexistent directory).
ESRCH No such process
No process matching the specified search criteria could be
found.
EINTR Interrupted system call
An asynchronous signal (such as interrupt or quit), which the
user had elected to catch, occurred during a system call. If
execution resumes after processing the signal, the interrupted
system call will return this error condition.
EIO I/O error
A physical I/O error occurred.
ENXIO No such device or address
The system encountered one of the following conditions: 1)
I/O on a special file referred to a nonexistent subdevice, or
to one that extended beyond the limits of the device; 2) a
device was not on-line; 3) no disk pack was loaded on a drive.
E2BIG Argument list too long
An argument list longer than ARG_MAX (10240) bytes was
presented to a member of the exec(2) family.
ENOEXEC Exec format error
A request was made to execute a file which, although it had
the appropriate permissions, did not start with a valid format
(see a.out(4)).
EBADF Bad file number
One of the following three file access errors occurred: 1) an
access request to an unopened file; 2) a read request to a
file that was open only for writing; 3) a write request to a
file that was open only for reading.
ECHILD No child processes
A wait was requested by a process that had no existing or
unwaited-for child processes.
EAGAIN or EWOULDBLOCK Resource temporarily unavailable
The system encountered one of the following conditions: 1) A
fork failed, either because the system's process table was
full or because the user was not allowed to create any more
processes; 2) A system call, such as a brk(2) or sbrk(2),
failed because of insufficient memory or swap space; 3) An
operation that would have caused a process to block was
attempted on an object in non-blocking mode (see ioctl(2)).
ENOMEM Not enough space
The system could not supply the memory required to complete
the system call.
EACCES Permission denied
The caller tried to access an object for which (s)he lacked
the required access privilege(s).
EFAULT Bad address
The system encountered a hardware fault in attempting to use
an argument of a system call.
ENOTBLK Block device required
A non-block file was specified where a block device was
required, e.g., in mount(2).
EBUSY Device or resource busy
The caller tried to do one of the following: 1) Mount a device
that was already mounted; 2) Unmount a device on which there
was an active file (open file, current directory, mounted-on
file, active text segment); 3) Enable accounting when it was
already enabled, or when the device or resource requested was
unavailable.
EEXIST File exists
An existing file was mentioned when a nonexistent one was
expected; e.g., link(2).
EXDEV Cross-device link
The caller tried to link to a file on another device, or
rename a file across devices.
ENODEV No such device
The caller tried to apply an inappropriate system call to a
device; e.g., a read request on a write-only device.
ENOTDIR Not a directory
The caller gave a non-directory reference where a directory
reference was required; e.g., in a path prefix or as an
argument to chdir(2).
EISDIR Is a directory
The caller attempted to open a directory file for writing.
EINVAL Invalid argument
The system encountered an invalid argument; e.g., a non-
mounted device in a umount call, an undefined signal in a
signal(2) or kill(2) call, or a negative pointer generated by
lseek(2) in a call to read(2) or write(2). Also supported by
the math functions described in the (3M) entries of this
manual.
ENFILE File table overflow
The system file table was full, and no more calls to open(2)
could be accepted.
EMFILE Too many open files
The caller attempted to open more than OPEN_MAX (by default,
64) file descriptors at a time.
ENOTTY Not a character device
The caller referenced a file that was not a character-special
device in a call to ioctl(2).
ETXTBSY Open Intent conflict
The caller attempted unbuffered I/O on a buffered I/O channel,
or vice versa.
EFBIG File too large
A file exceeded the maximum file size of ULIMIT; (by default,
1,082,201,088 bytes). See ulimit(2).
ENOSPC No space left on device
There was no free space left on a device during a write call
for an ordinary file,
ESPIPE Illegal seek
An lseek(2) was issued to a pipe or socket.
EROFS Read-only file system
The caller attempted to modify a file or directory on a device
that was mounted read-only.
EMLINK Too many links
The caller tried to make more than the maximum number of links
(LINK_MAX) to a file.
EPIPE Broken pipe
The caller attempted to write to a pipe for which there was no
process to read the data. This condition normally generates a
signal; the error is returned if the signal is ignored.
EDOM Math argument
A call to a mathematical function (i.e., one of the functions
in the 3M section of the manual) contained an argument out of
the domain of the function.
ERANGE Result too large
The value of a function in the math package (3M) could not be
represented within machine precision.
ENOMSG No message of desired type
The caller attempted to receive a message of a type that did
not exist on the specified message queue; see msgop(2).
EIDRM Identifier removed
An identifier was removed from the file system's name space.
This error is returned at the request of the a process so it
can resume execution. (See msgctl(2), semctl(2), and
shmctl(2)).
ECHRNG Channel number out of range
EL2NSYNC Level 2 not synchronized
EL3HLT Level 3 halted
EL3RST Level 3 reset
ELNRNG Link number out of range
EUNATCH Protocol driver not attached
ENOCSI No CSI structure available
EL2HLT Level 2 halted
EDEADLK Deadlock situation detected and avoided.
ENOLCK No record locks available
EBADE Invalid exchange
EBADR Invalid request descriptor
EXFULL Exchange full
ENOANO No anode
EBADRQC Invalid request code
EBADSLT Invalid slot
EDEADLOCK File-locking deadlock error
EBFONT Bad font file format
ENOSTR A STREAMs-only operation was attempted on a non-STREAMs file
ENODATA No data (for no-delay I/O)
ETIME Operation timed out
ENOSR STREAMs resources are not available
ENONET Machine is not on the network
ENOPKG Package not installed
EREMOTE Cannot mount a file system onto a remote directory
ENOLINK The link has been severed
EADV Advertise error
ESRMNT SRmount error
ECOMM Communication error on send
EPROTO Protocol error
EMULTIHOP Multihop attempted
EBADMSG Bad message type
ENAMETOOLONG Filename too long
ENOTUNIQ Given logname not unique
EBADFD File descriptor invalid for this operation
EREMCHG Remote address changed
ELIBACC Cannot access a needed shared library
ELIBBAD Accessing a corrupted shared library
ELIBSCN The .lib section in an executable is corrupted
ELIBMAX Attempting to link in too many shared libraries
ELIBEXEC Attempting to execute a shared library
ENOSYS Function not implemented
ELOOP Too many levels of symbolic links
ERESTART Restartable system call
EINPROGRESS Operation now in progress
An operation that takes a long time to complete (such as a
connect(2)) was attempted on a non-blocking object (see
ioctl(2)).
EALREADY Operation already in progress
ENOTSOCK Socket operation on non-socket
A socket-specific operation (such as bind(2)) was attempted on
a non-socket file.
EDESTADDRREQ Destination address required
A required address was omitted from an operation on a socket.
EMSGSIZE Message too long
A message sent on a socket exceeded the capacity of the
internal message buffer.
EPROTOTYPE Protocol wrong type for socket
The caller specified a protocol that does not support the
semantics of the socket type requested; e.g., the DARPA
Internet UDP protocol for a SOCK_STREAM socket.
ENOPROTOOPT Bad protocol option
The caller specified a bad option in a call to getsockopt(2)
or setsockopt(2).
EPROTONOSUPPORT Protocol not supported
The caller specified an unsupported protocol, or one that had
not been configured into the system.
ESOCKTNOSUPPORT Socket type not supported
The caller specified an unsupported socket type, or one that
had not been configured into the system.
EOPNOTSUPP Operation not supported on socket
For example, trying to use accept(2) with a connection on a
datagram socket.
EPFNOSUPPORT Protocol family not supported
The caller specified an unsupported protocol family, or one
that had not been configured into the system.
EAFNOSUPPORT Address family not supported by protocol family
The caller used an address that was incompatible with the
requested protocol, e.g., a PUP Internet address, which is
sometimes incompatible with DARPA Internet protocols.
EADDRINUSE Address already in use
The caller attempted more than one usage of an address.
EADDRNOTAVAIL Cannot assign requested address
Usually, this error indicates that the caller attempted to
create a socket with an address not on this machine.
ENETDOWN Network is down
A socket operation encountered a dead network.
ENETUNREACH Network is unreachable
The caller attempted a socket operation on an unreachable
network.
ENETRESET Network dropped connection on reset
The host to which the caller was connected crashed and
rebooted.
ECONNABORTED Software caused connection abort
An internal connection abort occurred on your host machine.
ECONNRESET Connection reset by peer
A connection was forcibly closed by a peer, most likely when
the peer executed a shutdown(2) call.
ENOBUFS No buffer space available
An operation on a socket or pipe could not be performed
because the system lacked sufficient buffer space.
EISCONN Socket is already connected
A connect(2) request was made on an already connected socket;
or, a sendto(2) or sendmsg(2) request on a connected socket
specified a destination other than the connected party.
ENOTCONN Socket is not connected
A request to send or receive data was disallowed because the
socket was not connected.
ESHUTDOWN Cannot send after socket shutdown
A request to send data was disallowed because the socket had
already been shut down with a previous shutdown(2) call.
ETOOMANYREFS Too many references; cannot splice.
ETIMEDOUT Connection timed out
A connect(2) request failed because the connected party did
not properly respond within the communications-protocol-
dependent timeout period.
ECONNREFUSED Connection refused
No connection could be made because the target machine
actively refused it, most likely because the caller attempted
to connect to a service that was inactive on the foreign host.
EHOSTDOWN Host is down
EHOSTUNREACH No route to host
ENOTEMPTY Directory not empty
EUSERS Too many users
EDQUOT Disk quota exceeded
ESTALE Stale NFS file handle
EPOWERFAIL Power failure occurred
EDGNOATTR No attribute
The object did NOT have the specified attribute.
ECLNRACE Race condition occurred
Race condition between clone open/open on stream. This is an
internal kernel error that is only used by the streams file
manager and the streams drivers. It is never returned to a
user program.
SEE ALSO
close(2), connect(2), ioctl(2), open(2), pipe(2), read(2),
shutdown(2), ulimit(2), write(2), intro(3), lockf(3C), perror(3C).
Licensed material--property of copyright holder(s)