INTRO(2)

NAME
intro, errno - introduction to system calls and error numbers

SYNOPSIS
#include <errno.h>

DESCRIPTION
Section 2 describes the entries into the kernel.

Calls that deal with file systems refer to directory entries by name. In order to read or write(2) data on a file, the file must be opened (open, pipe, creat(2)); an open file is known by a integer called a file descriptor. Certain open files admit control operations that alter their behavior; see in particular ioctl(2), stream(4), and ttyld(4).

Besides ordinary file systems, which are passive repositories of data, organized in a hierarchical directory structure, there are special file systems — virtual constructs with an interface that mimics an ordinary file system. In particular, access to files on remote computers is mediated by the special file system netfs(8). Other special file systems support proc(4) and faced(9.5).

SEE ALSO
intro(3)

DIAGNOSTICS
A `Diagnostics' paragraph appears below for each system call that has an error return. Unless otherwise stated, the error value is the integer -1, and the success value is 0. Upon an error return, an error number is assigned to the external variable errno. Errno is not cleared on successful calls, so it should be tested only after an error has occurred.

There is a table of messages that describe the errors and a routine for printing them; see perror(3). The list below gives the number, the name (as defined in <errno.h>), and the perror message for each error type. The reasons for error returns are explained in general terms; further explanations for less obvious error returns appear in the writeups of individual system calls. No error has occurred. An attempt was made to modify a file in some way forbidden except to its owner or the super-user, or an ordinary user attempted to do something allowed only to the super-user. A file name was specified and the file should exist but doesn't, or one of the directories in a path name does not exist. The process whose number was given to kill does not exist, or is already dead. An asynchronous signal (such as interrupt or quit), which the user has elected to catch, occurred during a system call. If execution is resumed after processing the signal, it will appear as if the interrupted system call returned this error condition. A physical I/O error or timeout occurred during read, write, or ioctl. This error may in some cases be returned on a call following the one to which it actually applies. I/O on a special file refers to a subdevice which does not exist, or beyond the limits of the device. It may also occur when, for example, a tape drive is off line or no disk pack is loaded on a drive. An argument list longer than 16384 bytes was presented to exec. A request was made to execute a file which, although it has the appropriate permissions, does not start with a valid magic number, see a.out(5). A file descriptor referred to no open file, or a read (resp. write) request was made to a file which is open only for writing (resp. reading). In a wait, the process had no living or unwaited-for children. In a fork, the system's process table was full or the user is not allowed to create any more processes. During an exec or brk, a program asked for more memory or swap space than the system is able to supply. An attempt was made to access a file in a way forbidden by the protection system. The system encountered a hardware fault in attempting to access the arguments of a system call. An attempt was made to remove a nonempty directory. An attempt was made to mount a device that was already mounted (or crashed or was copied in mounted state), to dismount a device on which there is an active file (open file, current directory, mounted-on file, active text segment), or to remove the current directory of some process. An existing file was mentioned in an inappropriate context, e.g. link. A link to a file on another device was attempted. An attempt was made to apply an inappropriate system call to a device; e.g. read a write-only device. A non-directory was specified where a directory is required, for example in a path name or as an argument to chdir. An attempt to write on a directory. Some invalid argument: dismounting a non-mounted device, mentioning an unknown signal in signal, reading or writing a file for which lseek has generated a negative pointer. Also set by math functions, see intro(3). The system's table of open files is full, and temporarily no more opens can be accepted. The limit is 128 per process. The function code mentioned in ioctl does not apply to the file or device. An attempt to execute a pure-procedure program which is currently open. Also an attempt to open for writing a pure-procedure program that is being executed. The size of a file exceeded the maximum (about 1.0E9 bytes). During a write to an ordinary file, there was no free space left on the device. An lseek was issued to a pipe or other non-seekable device. An attempt to modify a file or directory was made on a device mounted read-only. An attempt to make more than 32767 links to a file. A write on a pipe for which there is no process to read the data, or on a file with insufficient security clearance. This condition normally generates a signal; the error is returned if the signal is ignored. The argument of a function in the math package (3M) is out of the domain of the function. The value of a function in the math package (3M) is unrepresentable within machine precision. An endless cycle of symbolic links was encountered. The open was in violation of the concurrent access specified for the file, or an attempted IO operation violated a process exclusive (pex) lock. Something went wrong. An action which would, if completed, break security rules; see getplab(2). An attempt to execute a nonexistent or unsupported system call. A system table for security labels is full: a trouble similar to ENFILE. An attempt was made to execute a priviledged system call, or exercise a privileged feature of a regular system call.

SEE ALSO
perror(3)

BUGS
Device drivers and special file systems may use error codes in unexpected or unconventional ways; it is infeasible to list them all. For example, the crash of a remote computer or the failure of a communication protocol can produce (no such file or directory) in response to an attempt to open a file through the network file system.
To avoid publishing duplicates of trivially changed manual pages, is not recorded among diagnostics when that would be the only difference from v9.