intro(2) DG/UX 4.30 intro(2)
NAME
intro - introduction to system calls and error numbers
SYNOPSIS
#include <errno.h>
DESCRIPTION
This chapter describes all of the system calls. This
introduction is divided into two parts: DEFINITIONS and
ERRORS.
The DEFINITIONS section identifies important system
abstractions and describes them briefly in terms of their
representation in the system (that is, the superuser
abstraction is described in terms of its identity within the
system: a superuser process is one with an effective user
id of 0; it has special privileges). A summary of
definitions appears at the head of the section; both the
summary and the individual entries are grouped into
categories. The categories are: processes, files,
messages, semaphores, shared memory, interprocess
communications primitives, UNIX communications domain, and
Internet communications domain. Most entries are short and
do not suggest the programming contexts in which you use the
system calls mentioned; they generally refer you to one or
more individual system call descriptions in the manual.
However, the Interprocess Communications Primitives section
is a rather extensive discussion. It is taken from the
4.2BSD System Manual by Joy, Cooper, Fabry, Leffler,
McKusick, and Mosher, University of California, Berkeley,
Berkeley CA.
The ERRORS section lists the entire set of error conditions
by number, name, and description. At the end of the ERRORS
section is a discussion of implementation-dependent
constants that are referenced in the discussions of
individual calls.
DEFINITIONS
Processes
Process ID
A positive integer used to identify a process; each process
in the system has a unique process ID. The range of this ID
is from 0 to 30,000.
Parent Process ID
A new process is created by a currently active process; see
fork(2). The parent process ID of a process is the process
ID of its creator.
Licensed material--property of copyright holder(s) Page 1
intro(2) DG/UX 4.30 intro(2)
Process Group ID
Each active process is a member of a process group that is
identified by a positive integer called the process group
ID. This ID is the process ID of the group leader. This
grouping permits the signaling of related processes; see
kill(2).
Tty Group ID
Each active process can be a member of a terminal group that
is identified by a positive integer called the tty group ID.
The 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).
Real User ID and Real Group ID
Each user allowed on the system is identified by a positive
integer called a real user ID.
Each user is also a member of a group. The group is
identified by a positive integer called the real group ID.
An active process has a real user ID and real group ID that
are set to the real user ID and real group ID, respectively,
of the user who created the process.
Effective User ID and Effective Group ID
Each active process has an effective user ID and an
effective group ID that are used to determine file access
permissions (see below). The effective user ID and
effective group ID are equal to the process's real user ID
and real group ID respectively, 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).
Superuser
A process is recognized as a superuser process and is
granted special privileges if its effective user ID is 0.
Special Processes
Processes with a process ID of 0 or 1 are special processes
and are referred to as proc0 and proc1.
Proc0 is the scheduler. Proc1 is the initialization process
(init). Proc1 is the ancestor of every other process in the
system; it controls the process structure.
Licensed material--property of copyright holder(s) Page 2
intro(2) DG/UX 4.30 intro(2)
Files
Descriptor
An integer assigned by the system when a file is referenced
by creat(2), open(2), dup(2), fcntl(2), or pipe(2) or a
socket is referenced by socket(2) or socketpair(2). It
uniquely identifies an access path to that file or socket
from a given process or any of its children.
A process may have no more than 64 descriptors (0-63) open
simultaneously.
The descriptor is used as an argument by calls such as
read(2), write(2), ioctl(2), send(2), recv(2), and close(2).
The descriptor is known as the file descriptor in System V.
Filename
A filename is a character string that names an ordinary
file, special file or directory.
These characters may be selected from the set of all
character values excluding \0 (null) and the ASCII code for
/ (slash).
Avoid using *, ?, @, #, $, ^, &, (, ), `, |, ;, ', <, >, [,
or ] as part of filenames, since the shell attaches special
meanings to them. File names can be up to 255 characters.
See sh(1) and csh(1). Also avoid using unprintable
characters in filenames.
Path Name and Path Prefix
A path name is a null-terminated character string starting
with an optional slash (/), followed by zero or more
directory names separated by slashes, optionally followed by
a filename.
More precisely, a path name is a null-terminated character
string constructed as follows:
<path-name>::=<filename>|<path-prefix><filename>|/
<path-prefix>::=<rtprefix>|/<rtprefix>
<rtprefix>::=<dirname>/|<rtprefix><dirname>/
<filename> is a legal filename, and <dirname> is a legal
directory name. See File name above.
If a path name begins with a slash, the path search begins
at the root directory (/). Otherwise, the search begins
from the current working directory.
Licensed material--property of copyright holder(s) Page 3
intro(2) DG/UX 4.30 intro(2)
A slash by itself names the root directory.
Unless specifically stated otherwise, the null path name is
treated as if it named a non-existent file.
Directory
Directory entries are called links. By convention, a
directory contains at least two links, . and .., referred to
as dot and dot-dot respectively. Dot refers to the
directory itself and dot-dot refers to its parent directory.
Root Directory and Current Working Directory
Each process has associated with it a concept of a root
directory and a current working directory for the purpose of
resolving path name searches. The root directory of a
process need not be the root directory of the root file
system; see chroot(2).
File Access Permissions
Every file in the file system has a set of access
permissions, which determine whether a process may perform a
requested operation on the file. For example, opening a file
for writing is an operation subject to file access
permissions.
Every file has three classes of access permissions: owner,
group, and other. The classes identify types of users: the
owner of a file, a defined group of users, and all other
users.
Each class has its own set of three types of access
permissions: read (r), write (w), and execute (x). A
file's access permissions are set when the file is created.
They can be masked upon creation if umask(2) is in effect,
and they can be changed explicitly with chmod(2), chown(2),
or chgrp(2). When an access check is made, the system
decides if permission should be granted by comparing the
file's access permissions and the calling process's access
information.
All three permissions (read, write, and execute/search) on a
file are granted to a calling process if one or more of the
following are true:
The effective user ID of the calling process is
superuser.
The effective user ID of the calling process matches
the user ID of the owner of the file and the
Licensed material--property of copyright holder(s) Page 4
intro(2) DG/UX 4.30 intro(2)
appropriate access bits of the owner portion (0700) of
the file mode is set.
The effective user ID of the calling process does not
match the user ID of the owner of the file, the
effective group ID of the calling process matches the
group of the file, and the appropriate access bits of
the group portion (070) of the file mode is set.
The effective user ID of the calling process does not
match the user ID of the owner of the file, the
effective group ID of the calling process does not
match the group ID of the file, and the appropriate
access bits of the other portion (07) of the file mode
is set.
Otherwise, permissions are denied on the basis of permission
values in the file mode.
Messages
Message Queue Identifier
A message queue identifier (msqid) is a unique positive
integer created by a msgget(2) system call. The maximum
number of msqids allowed is configurable. The default is
50. Each msqid has a message queue and a data structure
associated with it. The data structure is referred to as
msqid_ds and contains the following members:
struct ipc_perm msg_perm; /* operation permission struct */
ushort msg_qnum; /* number of msgs on q */
ushort msg_qbytes; /* max number of bytes on q */
ushort msg_lspid; /* pid of last msgsnd operation */
ushort msg_lrpid; /* pid of last msgrcv operation */
time_t msg_stime; /* last msgsnd time */
time_t msg_rtime; /* last msgrcv time */
time_t msg_ctime; /* last change time */
/* all times are in secs since */
/* 00:00:00 GMT, Jan. 1, 1970 */
Msgperm is an ipc_perm structure, as declared in ipc.h,
that specifies the message operation permission (see below).
This structure includes the following members:
ushort cuid; /* creator user id */
ushort cgid; /* creator group id */
ushort uid; /* user id */
ushort gid; /* group id */
ushort mode; /* r/w permission */
Msgqnum is the number of messages currently on the queue.
Msgqbytes is the maximum number of bytes allowed on the
Licensed material--property of copyright holder(s) Page 5
intro(2) DG/UX 4.30 intro(2)
queue. Msglspid is the process ID of the last process that
performed a msgsnd operation. Msglrpid is the process ID
of the last process that performed a msgrcv operation.
Msgstime is the time of the last msgsnd operation,
msgrtime is the time of the last msgrcv operation, and
msgctime is the time the msgid was created by msgget(2) or
of the last msgctl(2) operation that changed a member of the
above structure.
Message Operation Permissions
In the msgop(2) and msgctl(2) system call descriptions, the
permission required for an operation is given as {token}.
Token is the type of permission needed interpreted as
follows:
00400 Read by user
00200 Write by user
00060 Read, write by group
00006 Read, write by others
Read and write permissions on a msqid are granted to a
process if one or more of the following are true:
The effective user ID of the process is superuser.
The effective user ID of the process matches
msgperm.[c]uid in the data structure associated with
msqid and the appropriate bit of the user portion
(0600) of msgperm.mode is set.
The effective user ID of the process does not match
msgperm.[c]uid , the effective group ID of the process
matches msgperm.[c]gid , and the appropriate bit of
the group portion (060) of msgperm.mode is set.
The effective user ID of the process does not match
msgperm.[c]uid , the effective group ID of the process
does not match msgperm.[c]gid , and the appropriate
bit of the other portion (06) of msgperm.mode is set.
Otherwise, the corresponding permissions are denied.
Semaphores
Semaphore Identifier
A semaphore identifier (semid) is a unique positive integer
created by a semget(2) system call. The maximum numbers of
identifiers is configurable; the default is 10. Each has a
set of semaphores and a data structure associated with it.
The data structure is referred to as semid_ds and contains
the following members:
Licensed material--property of copyright holder(s) Page 6
intro(2) DG/UX 4.30 intro(2)
struct ipc_perm sem_perm; /* operation permission struct */
ushort sem_nsems; /* number of sems in set */
time_t sem_otime; /* last operation time */
time_t sem_ctime; /* last change time */
/* all times are in secs since */
/* 00:00:00 GMT, Jan. 1, 1970 */
Semperm is an ipc_perm structure (as defined in ipc.h) that
specifies the semaphore operation permission (see below).
This structure includes the following members:
ushort cuid; /* creator user id */
ushort cgid; /* creator group id */
ushort uid; /* user id */
ushort gid; /* group id */
ushort mode; /* r/a permission */
The value of semnsems is equal to the number of semaphores
in the set. Each semaphore in the set is referenced by a
positive integer referred to as a sem_num. Sem_num values
run sequentially from 0 to the value of sem_nsems minus 1.
Semotime is the time of the last semop(2) operation, and
semctime is the time the sem_id was created by semget(2) or
of the last semctl(2) operation that changed a member of the
above structure.
A semaphore is a data structure that contains the following
members:
ushort semval; /* semaphore value */
short sempid; /* pid of last operation */
ushort semncnt; /* # awaiting semval > cval */
ushort semzcnt; /* # awaiting semval = 0 */
Semval is a non-negative integer in the range 0 to 30,000.
Sempid is equal to the process ID of the last process that
performed a semaphore operation on this semaphore. Semncnt
is the number of processes waiting for this semaphore's
semval to exceed its current value. Semzcnt is a count of
the number of processes that are currently suspended
awaiting this semaphore's semval to become zero.
Semaphore Operation Permissions
In the semop(2) and semctl(2) system call descriptions, the
permission required for an operation is given as {token}.
Token is interpreted as follows:
00400 Read by user
00200 Alter by user
00060 Read, alter by group
00006 Read, alter by others
Licensed material--property of copyright holder(s) Page 7
intro(2) DG/UX 4.30 intro(2)
Read and alter permissions on a semid are granted to a
process if one or more of the following are true:
The effective user ID of the process is superuser.
The effective user ID of the process matches
semperm.[c]uid in the data structure associated with
semid, and the appropriate bit of the user portion
(0600) of semperm.mode is set.
The effective user ID of the process does not match
semperm.[c]uid, the effective group ID of the process
matches semperm.[c]gid, and the appropriate bit of the
group portion (060) of semperm.mode is set.
The effective user ID of the process does not match
semperm.[c]uid, the effective group ID of the process
does not match semperm.[c]gid, and the appropriate bit
of the other portion (06) of semperm.mode is set.
Otherwise, the corresponding permissions are denied.
Shared Memory
Shared Memory Identifier
A shared memory identifier (shmid) is a unique positive
integer created by a shmget(2) system call. Each shmid has
a segment of memory (referred to as a shared memory segment)
and a data structure associated with it. The data structure
is referred to as shmid_ds and contains the following
members:
struct ipc_perm shm_perm; /* operation permission struct */
int shm_segsz; /* size of segment */
ushort shm_cpid; /* creator pid */
ushort shm_lpid; /* pid of last operation */
short shm_nattch; /* number of current attaches */
time_t shm_atime; /* last attach time */
time_t shm_dtime; /* last detach time */
time_t shm_ctime; /* last change time */
/* all times are in secs since */
/* 00:00:00 GMT, Jan. 1, 1970 */
Shmperm is an ipc_perm structure that specifies the shared
memory operation permission (see below). This structure
includes the following members:
ushort cuid; /* creator user id */
ushort cgid; /* creator group id */
ushort uid; /* user id */
ushort gid; /* group id */
ushort mode; /* r/w permission */
Licensed material--property of copyright holder(s) Page 8
intro(2) DG/UX 4.30 intro(2)
Shmsegsz specifies the size in bytes of the shared memory
segment. Shmcpid is the process ID of the process that
created the shared memory identifier. Shmlpid is the
process ID of the last process that performed a shmat(2) or
shmdt(2) operation. Shmnattch is the number of processes
that currently have this segment attached. Shmatime is the
time of the last shmat operation, shmdtime is the time of
the last shmdt operation, and shmctime is the time the
shm_id was created by shmget(2) or of the last shmctl(2)
operation that changed one of the members of the above
structure.
Shared Memory Operation Permissions
In the descriptions for the shmsys(2) family of system
calls, the permission required for an operation is given as
{token}, where token is interpreted as follows:
00400 Read by user
00200 Write by user
00060 Read, write by group
00006 Read, write by others
Read and write permissions on a shmid are granted to a
process if one or more of the following are true:
The effective user ID of the process is superuser.
The effective user ID of the process matches
shmperm.[c]uid in the data structure associated with
shmid, and the appropriate bit of the user portion
(0600) of shmperm.mode is set.
The effective user ID of the process does not match
shmperm.[c]uid, the effective group ID of the process
matches shmperm.[c]gid, and the appropriate bit of the
group portion (060) of shmperm.mode is set.
The effective user ID of the process does not match
shmperm.[c]uid, the effective group ID of the process
does not match shmperm.[c]gid, and the appropriate bit
of the other portion (06) of shmperm.mode is set.
Otherwise, the corresponding permissions are denied.
Interprocess Communication Primitives
This section (up to the ERRORS section) describes the DG/UX
IPC facilities, which are based on the Berkeley UNIX IPC
facilities.
Communication domains
Licensed material--property of copyright holder(s) Page 9
intro(2) DG/UX 4.30 intro(2)
The system provides access to an extensible set of
communication domains. A communication domain 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 for communication in the DARPA
internet, AF_INET. Other domains can be added to the
system.
NOTE:
The "internet" domain is not provided on the standard
DG/UX system. This domain is provided only with the
DG/UX TCP/IP product.
Socket types and protocols
Within a domain, communication takes place between
communication endpoints knows as sockets. Each socket has
queues for sending and receiving data; it may exchange data
with other sockets within its domain.
Sockets are typed according to their communications
properties. These properties include whether messages sent
and received at a socket require the name of the partner,
whether communication is reliable, what format is used in
naming message recipients, whether duplication is prevented,
etc.
Each kernel supports some collection of socket types;
consult socket(2) for more information about the types
available and their properties. The basic set of socket
types is defined in <sys/socket.h>:
/* Standard socket types */
#define SOCK_DGRAM 1 /* datagram */
#define SOCK_STREAM 2 /* virtual circuit */
#define SOCK_RAW 3 /* raw socket */
#define SOCK_RDM 4 /* reliably-delivered message */
#define SOCK_SEQPACKET 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, 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
Licensed material--property of copyright holder(s) Page 10
intro(2) DG/UX 4.30 intro(2)
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. (DG/UX does not support
the SOCK_RDM and SOCK_SEQPACKET types.)
Each socket may have a concrete protocol associated with it.
This protocol is used within the domain to provide the
semantics required by the socket type. For example, within
the "internet" domain, the SOCK_DGRAM type may be
implemented by the UDP user datagram protocol, and the
SOCK_STREAM type may be implemented by the TCP transmission
control protocol, 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, naming and service establishment
Sockets may be connected or unconnected. An unconnected
socket descriptor is obtained by the socket call:
s = socket(domain, type, protocol);
result int s; int domain, type, protocol;
An unconnected socket descriptor may yield a connected
socket descriptor in one of two ways: either by actively
connecting to another socket, or by becoming associated with
a name in the communications domain and accepting a
connection from another socket.
To accept connections, a socket must first have a binding to
a name within the communications domain. Such a binding is
established by a bind call:
bind(s, name, namelen);
int s; char *name; int namelen;
A socket's bound name may be retrieved with a getsockname
call:
getsockname(s, name, namelen);
int s; result caddr_t name; result int *namelen;
Licensed material--property of copyright holder(s) Page 11
intro(2) DG/UX 4.30 intro(2)
while the peer's name can be retrieved with getpeername:
getpeername(s, name, namelen);
int s; result caddr_t name; result int *namelen;
Domains may support sockets with several names.
Accepting connections
Once a binding is made, it is possible to listen for
connections:
listen(s, backlog);
int s, backlog;
The backlog specifies the maximum count of connections that
can be simultaneously queued awaiting acceptance.
An accept call:
t = accept(s, name, anamelen);
result int t; int s; result caddr_t name; result int
*anamelen;
returns a descriptor for a new, connected, socket from the
queue of pending connections on s.
Making connections
An active connection to a named socket is made by the
connect call:
connect(s, name, namelen);
int s; caddr_t name, int namelen;
It is also possible to create connected pairs of sockets
without using the domain's name space to rendezvous; this is
done with the socketpair call: (DG/UX supports socketpair
creation only in the "unix" communication domain.)
socketpair(d, type, protocol, sv);
int d, type, protocol; result int sv [2];
Here the returned sv descriptors correspond to those
obtained with accept and connect.
Sending and receiving data
Messages may be sent from a socket by:
cc = sendto(s, buf, len, flags, to, tolen);
result int cc; int s; caddr_t buf; int len, flags;
Licensed material--property of copyright holder(s) Page 12
intro(2) DG/UX 4.30 intro(2)
caddr_t to; int tolen;
if the socket is not connected or:
cc = send(s, buf, len, flags);
result int cc; int s; caddr_t buf; int len, flags;
if the socket is connected. The corresponding receive
primitives are:
msglen = recvfrom(s, buf, len, flags, from,
fromlenaddr);
result int msglen; int s; result caddr_t buf; int len,
flags;
result caddr_t from; result int *fromlenaddr;
and
msglen = recv(s, buf, len, flags);
result in msglen; int s; result caddr_t buf; int len,
flags;
In the unconnected case, the parameters to and tolen specify
the destination or source of the message, while the from
parameter stores the source of the message, and fromlenaddr
initially gives the size of the from buffer and is updated
to reflect the true length of the from address.
All calls cause the message to be received in or sent from
the message buffer of length len bytes, starting at address
buf. The flags specify peeking at a message without reading
it or sending or receiving high-priority out-of-band
messages, as follows:
#define MSG_PEEK 0x1 /* peek at incoming message */
#define MSG_OOB 0x2 /* process out-of-band data */
Scatter/gather and exchanging access rights
It is possible scatter and gather data and to exchange
access rights with messages. When either of these
operations is involved, the number of parameters to the call
becomes large. Thus the system defines a message header
structure, in <sys/socket.h>, which can be used to
conveniently contain the parameters to the calls:
struct msghdr {
caddr_t msg_name; /* optional address */
int msg_namelen; /* size of address */
struct iov *msg_iov; /* scatter/gather array */
int msg_iovlen; /* #elements in msg_iov */
Licensed material--property of copyright holder(s) Page 13
intro(2) DG/UX 4.30 intro(2)
caddr_t msg_accrights; /* access rights sent/received */
int msg_accrightslen; /* size of msg_accrights */
};
Here msg_name and msg_namelen specify the source or
destination address if the socket is unconnected; msg_name
may be given as a null pointer if no names are desired or
required. The msg_iov and msg_iovlen describe the
scatter/gather locations.
This structure is used in the operations sendmsg and
recvmsg:
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;
Using read and write with sockets
The normal DG/UX read and write calls may be applied to
connected sockets and translated by the system into send and
receive. A process may operate on a virtual circuit socket,
a terminal or a file with blocking or non-blocking
input/output operations without distinguishing the
descriptor type.
Shutting down halves of full-duplex connections
A process that has a full-duplex socket such as a virtual
circuit and no longer wishes to read from or write to this
socket can give the call:
shutdown(s, direction);
int s, direction;
where direction is 0 to not read further, 1 to not write
further, or 2 to completely shut the connection down.
Socket and protocol options
Sockets and their underlying communication protocols may
support options. These options may be used to manipulate
implementation specific or non-standard facilities. The
getsockopt and setsockopt calls are used to control options:
getsockopt(s, level, optname, optval, optlen)
int s, level, optname; result caddr_t optval;
result int *optlen;
Licensed material--property of copyright holder(s) Page 14
intro(2) DG/UX 4.30 intro(2)
setsockopt(s, level, optname, optval, optlen)
int s, level, optname; caddr_t 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 which 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.
Types of sockets
In the UNIX domain, the SOCK_STREAM abstraction provides
pipe-like facilities, while SOCK_DGRAM provides reliable
message-style communications.
Naming
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.
Socket types and protocols
SOCK_STREAM is supported by the INTERNET TCP protocol;
SOCK_DGRAM by 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.
Socket naming
Sockets in the INTERNET domain have names composed of the 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.
Access rights transmission
No access rights transmission facilities are provided in the
INTERNET domain.
Licensed material--property of copyright holder(s) Page 15
intro(2) DG/UX 4.30 intro(2)
Raw access
The INTERNET domain allows the super-user access to the raw
facilities of the various network interfaces and the various
internal layers of the protocol implementation. This allows
administrative and debugging functions to occur. These
interfaces are modeled as SOCK_RAW sockets.
ERRORS
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 could return. 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; they are defined in <errno.h>.
Numbering
1 EPERM Not owner
This error usually indicates an attempt to modify a
file in some way forbidden except to its owner or to
the super-user. It also indicates attempts by ordinary
users to do things allowed only to the super-user.
2 ENOENT No such file or directory
This error occurs when you try to use a pathname that
is too long, refer to a file that doesn't exist, or use
a path name that includes an invalid directory name
(e.g., the directory doesn't exist).
3 ESRCH No such process
No process can be found corresponding to that specified
by pid in kill or ptrace.
4 EINTR Interrupted system call
An asynchronous signal (such as interrupt or quit),
which the user has elected to catch, occurred during a
system call. If execution resumes after processing the
signal, the interrupted system call will seem to return
this error condition.
5 EIO I/O error
Some physical I/O error has occurred. This error may
Licensed material--property of copyright holder(s) Page 16
intro(2) DG/UX 4.30 intro(2)
occur on a call following the one to which it actually
applies.
6 ENXIO No such device or address
I/O on a special file refers to a subdevice that does
not exist, or that extends beyond the limits of the
device. It may also occur when a device is not on-line
or no disk pack is loaded on a drive.
7 E2BIG Argument list too long
An argument list longer than 5,120 bytes is presented
to a member of the exec family.
8 ENOEXEC Exec format error
A request is made to execute a file which, although it
has the appropriate permissions, does not start with a
valid magic number (see a.out(4)).
9 EBADF Bad file number
Occurs under any of three conditions: a file descriptor
refers to no open file; a read request is made to a
file that is open only for writing; a write request is
made to a file that is open only for reading.
10 ECHILD No child processes
A wait was executed by a process that had no existing
or unwaited-for child processes.
11 EAGAIN or EWOULDBLOCK Resource temporarily unavailable
A fork failed because the system's process table is
full or the user is not allowed to create any more
processes. Or a system call, such as a brk or sbrk,
failed because of insufficient memory or swap space.
Or, an operation that would cause a process to block
was attempted on a object in non-blocking mode (see
ioctl(2)).
12 ENOMEM Not enough space
During a brk or sbrk, a program asks for more space
than the system can supply. If a shared memory segment
exists, this could be a temporary condition. The
maximum space size is a system parameter. The
parameter is a program size switch that is set for the
linker. The usual size is 1M bytes, maximum is 512M
bytes.
13 EACCES Permission denied
You tried to access a file in a way forbidden by the
protection system.
14 EFAULT Bad address
The system encountered a hardware fault in attempting
Licensed material--property of copyright holder(s) Page 17
intro(2) DG/UX 4.30 intro(2)
to use an argument of a system call.
15 ENOTBLK Block device required
A non-block file was mentioned where a block device was
required, e.g., in mount.
16 EBUSY Device or resource busy
You tried to mount a device that was already mounted or
to dismount a device on which there is an active file
(open file, current directory, mounted-on file, active
text segment). This error will also occur if you try
to enable accounting when it is already enabled, or if
device or resource requested is currently unavailable.
17 EEXIST File exists
An existing file was mentioned in an inappropriate
context; e.g., link(2).
18 EXDEV Cross-device link
You tried to link to a file on another device.
19 ENODEV No such device
You tried to apply an inappropriate system call to a
device; e.g., read a write-only device.
20 ENOTDIR Not a directory
You gave a non-directory reference where a directory
reference is required: for example, in a path prefix
or as an argument to chdir(2).
21 EISDIR Is a directory
An attempt was made to write on a directory.
22 EINVAL Invalid argument
Some invalid argument; e.g., dismounting a non-mounted
device, mentioning an undefined signal in signal or
kill, reading or writing a file for which lseek has
generated a negative pointer. Also set by the math
functions described in the (3M) entries of this manual.
23 ENFILE File table overflow
The system file table is full, and no more opens can be
accepted now.
24 EMFILE Too many open files
No process may have more than 64 file descriptors open
at a time.
25 ENOTTY Not a character device
You tried to ioctl(2) a file that is not a special
character device.
Licensed material--property of copyright holder(s) Page 18
intro(2) DG/UX 4.30 intro(2)
26 ETXTBSY Text file busy
You tried to execute a pure-procedure program that is
currently open for writing. Also occurs if you try to
open for writing a pure-procedure program that is being
executed.
27 EFBIG File too large
A file exceeded the maximum file size (1,082,201,088
bytes) or ULIMIT; see ulimit(2).
28 ENOSPC No space left on device
During a write to an ordinary file, there is no free
space left on the device.
29 ESPIPE Illegal seek
An lseek was issued to a pipe or socket.
30 EROFS Read-only file system
You tried to modify a file or directory on a device
mounted read-only.
31 EMLINK Too many links
You tried to make more than the maximum number of links
(1000) to a file.
32 EPIPE Broken pipe
A write on a pipe for which there is no process to read
the data. This condition normally generates a signal;
the error is returned if the signal is ignored.
33 EDOM Math argument
The argument of a function in the math package (3M) is
out of the domain of the function.
34 ERANGE Result too large
The value of a function in the math package (3M) is not
representable within machine precision.
35 ENOMSG No message of desired type
An attempt was made to receive a message of a type that
does not exist on the specified message queue; see
msgop(2).
36 EIDRM Identifier removed
This error is returned to processes that resume
execution due to the removal of an identifier from the
file system's name space (see msgctl(2), semctl(2), and
shmctl(2)).
37 ECHRNG Channel number out of range
Licensed material--property of copyright holder(s) Page 19
intro(2) DG/UX 4.30 intro(2)
38 EL2NSYNC Level 2 not synchronized
39 EL3HLT Level 3 halted
40 EL3RST Level 3 reset
41 ELNRNG Link number out of range
42 EUNATCH Protocol driver not attached
43 ENOCSI No CSI structure available
44 EL2HLT Level 2 halted
45 EDEADLK Deadlock in lockf
46 ENOLCK No record locks available
50 EBADE Invalid exchange
51 EBADR Invalid request descriptor
52 EXFULL Exchange full
53 ENOANO No anode
54 EBADRQC Invalid request code
55 EBADSLT Invalid slot
56 EDEADLOCK File locking deadlock error
57 EBFONT Bad font file format
60 ENOSTR A streams-only operation was attempted on a
Licensed material--property of copyright holder(s) Page 20
intro(2) DG/UX 4.30 intro(2)
non-stream file
61 ENODATA No data (for no-delay I/O)
62 ETIME Operation timed out
63 ENOSR Streams resources are not available
64 ENONET Machine is not on the network
65 ENOPKG Package not installed
66 EREMOTE Cannot mount a file system onto a remote
directory
67 ENOLINK The link has been severed
68 EADV Advertise error
69 ESRMNT SRmount error
70 ECOMM Communication error on send
71 EPROTO Protocol error
74 EMULITHOP Multihop attempted
77 EBADMSG Bad message type
78 ENAMETOOLONG File name too long
80 ENOTUNIQ Given logname not unique
81 EBADFD File descriptor invalid for this operation
Licensed material--property of copyright holder(s) Page 21
intro(2) DG/UX 4.30 intro(2)
82 EREMCHG Remote address changed
83 ELIBACC Cannot access a needed shared library
84 ELIBBAD Accessing a corrupted shared library
85 ELIBSCN The .lib section in an executable is corrupted
86 ELIBMAX Attempting to link in too many shared libraries
87 ELIBEXEC Attempting to execute a shared library
89 ENOSYS Function not implemented
90 ELOOP Too many levels of symbolic links
91 ERESTART Restartable system call
128 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)).
129 EALREADY Operation already in progress
130 ENOTSOCK Socket operation on non-socket
Self-explanatory.
131 EDESTADDRREQ Destination address required
A required address was omitted from an operation on a
socket.
132 EMSGSIZE Message too long
A message sent on a socket was larger than the internal
message buffer.
133 EPROTOTYPE Protocol wrong type for socket
You specified a protocol that does not support the
semantics of the socket type requested. For example,
you cannot use the DARPA Internet UDP protocol with
type SOCK_STREAM.
Licensed material--property of copyright holder(s) Page 22
intro(2) DG/UX 4.30 intro(2)
134 ENOPROTOOPT Bad protocol option
You specified a bad option in a getsockopt(2) or
setsockopt(2) call.
135 EPROTONOSUPPORT Protocol not supported
The protocol has not been configured into the system or
no implementation for it exists.
136 ESOCKTNOSUPPORT Socket type not supported
The support for the socket type has not been configured
into the system or no implementation for it exists.
137 EOPNOTSUPP Operation not supported on socket
For example, trying to accept a connection on a
datagram socket.
138 EPFNOSUPPORT Protocol family not supported
The protocol family has not been configured into the
system or no implementation for it exists.
139 EAFNOSUPPORT Address family not supported by protocol
family
You used an address incompatible with the requested
protocol. For example, you can't always use PUP
Internet addresses with DARPA Internet protocols.
140 EADDRINUSE Address already in use
Only one usage of each address is normally permitted.
141 EADDRNOTAVAIL Cannot assign requested address
This error usually results from an attempt to create a
socket with an address not on this machine.
142 ENETDOWN Network is down
A socket operation encountered a dead network.
143 ENETUNREACH Network is unreachable
A socket operation was attempted to an unreachable
network.
144 ENETRESET Network dropped connection on reset
The host you were connected to crashed and rebooted.
145 ECONNABORTED Software caused connection abort
A connection abort was caused internal to your host
machine.
146 ECONNRESET Connection reset by peer
A connection was forcibly closed by a peer. This
normally results from the peer executing a shutdown(2)
call.
Licensed material--property of copyright holder(s) Page 23
intro(2) DG/UX 4.30 intro(2)
147 ENOBUFS No buffer space available
An operation on a socket or pipe was not performed
because the system lacked sufficient buffer space.
148 EISCONN Socket is already connected
A connect request was made on an already connected
socket; or, a sendto or sendmsg request on a connected
socket specified a destination other than the connected
party.
149 ENOTCONN Socket is not connected
An request to send or receive data was disallowed
because the socket was not connected.
150 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.
151 ETOOMANYREFS
Too many references; cannot splice.
152 ETIMEDOUT Connection timed out
A connect request failed because the connected party
did not properly respond after a period of time. (The
timeout period depends on the communication protocol.)
153 ECONNREFUSED Connection refused
No connection could be made because the target machine
actively refused it. This usually results from trying
to connect to a service that is inactive on the foreign
host.
156 EHOSTDOWN Host is down
157 EHOSTUNREACH No route to host
158 ENOTEMPTY Directory not empty
159 EPROCLIM (Not used in DG/UX)
160 EUSERS Too many users
161 EDQUOT Disk quota exceeded used in NFM
Licensed material--property of copyright holder(s) Page 24
intro(2) DG/UX 4.30 intro(2)
162 ESTALE Stale file handle
163 EPOWERFAIL Power failure occurred
SEE ALSO
close(2), ioctl(2), open(2), pipe(2), read(2), write(2),
lockf(2), shutdown(2), ulimit(2), connect(2), intro(3),
perror(3).
Licensed material--property of copyright holder(s) Page 25