intro(2)
_________________________________________________________________
intro System Call
introduction to system calls and error numbers
_________________________________________________________________
SYNTAX
#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 (e. g., 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 entry for
interprocess communications primitives 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.
DG/UX 4.00 Page 1
Licensed material--property of copyright holder(s)
intro(2)
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.
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
DG/UX 4.00 Page 2
Licensed material--property of copyright holder(s)
intro(2)
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.
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>/
DG/UX 4.00 Page 3
Licensed material--property of copyright holder(s)
intro(2)
<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.
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.
DG/UX 4.00 Page 4
Licensed material--property of copyright holder(s)
intro(2)
The effective user ID of the calling process matches the
user ID of the owner of the file and the 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 */
DG/UX 4.00 Page 5
Licensed material--property of copyright holder(s)
intro(2)
Msgqnum is the number of messages currently on the queue.
Msgqbytes is the maximum number of bytes allowed on the 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
DG/UX 4.00 Page 6
Licensed material--property of copyright holder(s)
intro(2)
of semaphores and a data structure associated with it. The data
structure is referred to as semid_ds and contains the following
members:
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:
DG/UX 4.00 Page 7
Licensed material--property of copyright holder(s)
intro(2)
00400 Read by user
00200 Alter by user
00060 Read, alter by group
00006 Read, alter by others
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
DG/UX 4.00 Page 8
Licensed material--property of copyright holder(s)
intro(2)
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 */
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 shmop(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 shmop(2) and shmctl(2) system call descriptions, 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.
DG/UX 4.00 Page 9
Licensed material--property of copyright holder(s)
intro(2)
Interprocess Communication Primitives
This section (from here up until the ERRORS section) describes
the DG/UX IPC facilities, which are based on the Berkeley UNIX
IPC facilities.
Communication domains
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 TCP/IP
(DG/UX) 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
DG/UX 4.00 Page 10
Licensed material--property of copyright holder(s)
intro(2)
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 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;
DG/UX 4.00 Page 11
Licensed material--property of copyright holder(s)
intro(2)
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;
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
DG/UX 4.00 Page 12
Licensed material--property of copyright holder(s)
intro(2)
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; 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 */
DG/UX 4.00 Page 13
Licensed material--property of copyright holder(s)
intro(2)
struct iov *msg_iov; /* scatter/gather array */
int msg_iovlen; /* #elements in msg_iov */
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;
DG/UX 4.00 Page 14
Licensed material--property of copyright holder(s)
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.
DG/UX 4.00 Page 15
Licensed material--property of copyright holder(s)
intro(2)
Access rights transmission
No access rights transmission facilities are provided in the
INTERNET domain.
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.
DG/UX 4.00 Page 16
Licensed material--property of copyright holder(s)
intro(2)
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 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 Operation would block
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.
DG/UX 4.00 Page 17
Licensed material--property of copyright holder(s)
intro(2)
14 EFAULT Bad address
The system encountered a hardware fault in attempting 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
DG/UX 4.00 Page 18
Licensed material--property of copyright holder(s)
intro(2)
You tried to ioctl(2) a file that is not a special character
device.
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
DG/UX 4.00 Page 19
Licensed material--property of copyright holder(s)
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 EWOULDBLOCK Operation would block
An operation that would cause a process to block was
attempted on a object in non-blocking mode (see ioctl (2)).
46 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)).
47 EALREADY Operation already in progress
48 ENOTSOCK Socket operation on non-socket
Self-explanatory.
49 EDESTADDRREQ Destination address required
A required address was omitted from an operation on a
socket.
50 EMSGSIZE Message too long
A message sent on a socket was larger than the internal
message buffer.
51 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.
52 ENOPROTOOPT Bad protocol option
You specified a bad option in a getsockopt(2) or
DG/UX 4.00 Page 20
Licensed material--property of copyright holder(s)
intro(2)
setsockopt(2) call.
53 EPROTONOSUPPORT Protocol not supported
The protocol has not been configured into the system or no
implementation for it exists.
54 ESOCKTNOSUPPORT Socket type not supported
The support for the socket type has not been configured into
the system or no implementation for it exists.
55 EOPNOTSUPP Operation not supported on socket
For example, trying to accept a connection on a datagram
socket.
56 EPFNOSUPPORT Protocol family not supported
The protocol family has not been configured into the system
or no implementation for it exists.
57 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.
58 EADDRINUSE Address already in use
Only one usage of each address is normally permitted.
59 EADDRNOTAVAIL Can't assign requested address
This error usually results from an attempt to create a
socket with an address not on this machine.
60 ENETDOWN Network is down
A socket operation encountered a dead network.
61 ENETUNREACH Network is unreachable
A socket operation was attempted to an unreachable network.
62 ENETRESET Network dropped connection on reset
The host you were connected to crashed and rebooted.
63 ECONNABORTED Software caused connection abort
A connection abort was caused internal to your host machine.
64 ECONNRESET Connection reset by peer
A connection was forcibly closed by a peer. This normally
results from the peer executing a shutdown (2) call.
65 ENOBUFS No buffer space available
An operation on a socket or pipe was not performed because
the system lacked sufficient buffer space.
66 EISCONN Socket is already connected
DG/UX 4.00 Page 21
Licensed material--property of copyright holder(s)
intro(2)
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.
67 ENOTCONN Socket is not connected
An request to send or receive data was disallowed because
the socket was not connected.
68 ESHUTDOWN Can't 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.
69 ETOOMANYREFS
Too many references; can't splice.
70 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.)
71 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.
72 ELOOP Too many levels of symbolic link
73 ENAMETOOLONG File name too long
74 EHOSTDOWN Host is down
75 EHOSTUNREACH No route to host
76 ENOTEMPTY Directory not empty
77 EPROCLIM (Not used in DG/UX)
78 EUSERS Too many users
79 EDQUOT Disk quota exceeded used in NFM
80 EDEADLOCK or EDEADLK Deadlock in lockf
81 EMAXUSER Maximum number of concurrent users exceeded
82 ESTALE Stale file handle
83 EREMOTE Cannot mount a file system onto a remote directory
84 ENOSR Streams resources not available
DG/UX 4.00 Page 22
Licensed material--property of copyright holder(s)
intro(2)
85 ETIME Streams operation timed out
86 EBADMSG Bad streams message type
87 ENOSTR A streams-only operator was attempted on a non-stream
file
88 ENOLCK No record locks available
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).
DG/UX 4.00 Page 23
Licensed material--property of copyright holder(s)