Linux Programming Chris Seddon

Transcription

1 Linux Programming Chris Seddon CRS Enterprises Ltd 1

2 CRS Enterprises Ltd 2

3 Linux Programming 1. The Unix Model 2. File Input and Output 3. Files and Directories 4. Signals 5. Creating New Processes 6. Pipes and FIFOs 7. System V IPC Overview 8. Message Queues 9. Semaphores 10. Memory Management 11. Introduction to Sockets 12. Unix Domain Sockets 13. Internet Domain Sockets 14. File Locking 15. Terminals 16. STREAMS 17. Groups, Sessions and Daemons CRS Enterprises Ltd 3

4 CRS Enterprises Ltd 4

5 Chapter 1 1 Copyright CRS Enterprises Ltd CRS Enterprises Ltd 5

6 The Unix Model 1 Copyright CRS Enterprises Ltd CRS Enterprises Ltd 6

7 Unix for Programmers Structure of Unix Debugging Standards Processes System Calls and Library Functions Error Handling Copyright CRS Enterprises Ltd CRS Enterprises Ltd 7

8 Standards C Standard 1991 ANSI C C++ Standard 1997 ANSI C++ Standard Unix Operating System SVR4 Unix API Standards 1993 POSIX 1 - System Calls 1997 POSIX 4 - Real Time Extensions (draft) 1997 POSIX 4b - Threads (draft) Copyright CRS Enterprises Ltd CRS Enterprises Ltd 8

9 Documentation Manual Pages Volume 1 Volume 2 Volume 3 Volume 5 Unix Commands System Calls Library Functions Data Structures X Windows Help Xman Copyright CRS Enterprises Ltd CRS Enterprises Ltd 9

10 Debugging UnixWare Character Mode X Windows Mode debug -I c ExeFile ParameterList debug ExeFile ParameterList SVR4/BSD Character Mode X Windows Mode dbx xdbx Assembler Processes Kernel kadb adb Copyright CRS Enterprises Ltd CRS Enterprises Ltd 10

11 The Structure of Unix C function library awk libc libm xterm cat memory management device interfaces 123 vi hardware kernel oracle date multitasking file system sort ksh grep cc System call interface Copyright CRS Enterprises Ltd CRS Enterprises Ltd 11

12 Processes Process Table 500 Process Area STACK HOLE HEAP DATA TEXT User Area Command Line Environment Variables Open File Tables Signal Handlers Timers IPC Handles Exit Status Copyright CRS Enterprises Ltd CRS Enterprises Ltd 12

13 System Calls and Library Functions Application Kernel Hardware ch scanf() User read() kernel page stdin Run Time Library Copyright CRS Enterprises Ltd CRS Enterprises Ltd 13

14 Making System Calls USER KERNEL read(...) trap handler getpid() getpid() shmget(...) syscall() system call dispatch read(...) shmget(...) Copyright CRS Enterprises Ltd CRS Enterprises Ltd 14

15 Error Codes errno errno symbol symbol meaning 1 EPERM EPERM Not Not super-user 2 ENOENT No No such such file file or or directory 3 ESRCH ESRCH No No such such process, process, LWP, LWP, or or thread thread 4 EINTR EINTR Interrupted system system call call 5 EIO EIO I/O I/O error error 6 ENXIO ENXIO No No such such device device or or address address 7 E2BIG E2BIG Argument list list too too long long 8 ENOEXEC Exec Exec format format error error 9 EBADF EBADF Bad Bad file file number number ECHILD No No child child processes /usr/include/errno.h Copyright CRS Enterprises Ltd CRS Enterprises Ltd 15

16 Errors and Diagnostics #include <stdio.h> /* /* for for perror() */ */ #include <errno.h> /* /* for for errno errno */ */ void void main(void) {{ pid_t pid_t pid, pid, ppid; ppid; pid pid = getpid(); if if (pid (pid < 0) 0) {{ fprintf(stderr, "error "error%i\n", errno); errno); exit(1); exit(1); }} ppid ppid = getppid(); if if (ppid (ppid < 0) 0) {{ perror("getppid failed"); exit(1); exit(1); }} }} Copyright CRS Enterprises Ltd 16 The example above shows two typical system calls: getpid() getppid() returns the process's id. returns the parent's process id. In both cases we check the return code from the system call to see if it has failed. With getpid() we print a message that echoes the value of errno. Since we included the file <errno.h>, we have direct access to the variable. With getppid() we use perror() to print a meaningful message based on errno. perror() prints its parameter followed by the error message, so we may see something like: get ppid failed: no such process The manual pages for the system calls will contain definitive information about the possible error conditions and what may cause them. A list of error numbers and descriptions can be found under intro in volume 2 of the manual pages CRS Enterprises Ltd 16

17 2 Copyright CRS Enterprises Ltd CRS Enterprises Ltd 17

18 File Input and Output 2 Copyright CRS Enterprises Ltd CRS Enterprises Ltd 18

19 Basic Unix I/O Device Independence Inodes System calls File descriptors Copyright CRS Enterprises Ltd 19 This chapter will review standard I/O routines for accessing files, introduce the concept of the virtual file interface and explain inodes and file descriptors. The standard lowlevel I/O routines are also described in detail CRS Enterprises Ltd 19

20 Device Independence Key Unix concept Devices accessed through same interface as disk files Each file identified by its inode Directories are files which map strings (names) into inodes Copyright CRS Enterprises Ltd 20 Unix has a virtual-file interface to devices, which means that all devices are accessed in the same manner as files. The Unix file-system routines in the kernel recognize when a special file (e.g. a device) is accessed and redirect the I/O operations to the appropriate handling code. The device-handler routines then map the file operations into equivalent device operations. In order to keep track of all the files in a Unix hierarchical file system, there is a unique list of all the files on a file system. This list, called the inode list, is stored as part of the file-system structure information on the disk. A directory is a file that contains records that map names onto inode numbers. When accessing files by name, Unix reads each part of the pathname and looks in the next directory for the inode corresponding to that name. If this file is a directory, it becomes the directory to search for the next component of the pathname. More than one directory entry can refer to the same inode number, thereby allowing Unix file systems to have multiple links to the same file. Links are important because they allow a single file to be known by more than one pathname. Without links, the two special names "." and ".." would have to be treated as special cases when evaluating a pathname; with links, they are simply names in the directory file CRS Enterprises Ltd 20

21 inodes inodes data blocks owner group size file permissions time stamps 2K 8K 8K 8K 8K8K8K 8K 8K 10 direct 8K 1 indirect 1 double indirect 8K Copyright CRS Enterprises Ltd 21 The inode is a data structure that describes the attributes of the file. These attributes include creation, modification and access times, owner and group ids, protection and attribute flags and type of file (file, directory, device, etc.). In the case of a regular file or directory, the inode also contains information that defines the blocks on the disk that contain the data. Every file has a single inode allocated to it. When the inode list is full, no new files can be created, even if the disk still has unused file-data blocks. A file's inode number can be obtained with the ls -i command. A device file is fully defined by its inode; other types of file require allocated disk space to hold the data. The inode contains 13 pointers to data blocks. The first 10 point directly to the data blocks (direct pointers). The next pointer points to a block that contains pointers to the actual data blocks (indirect). The next inode pointer points to a block that contains pointers to the blocks that contain the pointers to the actual data blocks (doubleindirect). The last inode pointer is a triple-indirect pointer (not used on modern systems). Originally, the file system's data blocks were only 512 bytes. Using such a small block size gives very poor I/O performance and nowadays most systems use 8KB data blocks CRS Enterprises Ltd 21

22 open() int int open(char *path, int int oflag, int int mode) file file descriptor or or -1-1 pathname of of file file to to open open O_RDONLY O_WRONLY O_RDWR O_NDELAY O_CREAT O_EXCL O_APPEND O_TRUNC Usually Usually 0 unless unless O_CREAT is is set set fd = open("file1", O_RDWR O_APPEND O_CREAT, 0664); Copyright CRS Enterprises Ltd 22 The open system call is used to open a file descriptor. File descriptors must be opened before they can be read from or written to. The first parameter is the full pathname of the file (relative or absolute) and the second parameter is the I/O access flags. The access flags contain one of the following: O_RDONLY O_WRONLY O_RDWR Open for read only. Open for write only. Open for read and write. Other modes can be used in conjunction with the access flags: O_NDELAY If it is set, it will perform non-blocking I/O. Read will return immediately if no data present. Writes will initiate the write but not wait for completion. With this bit clear, reads will block until data arrives and writes will block until data has been written. O_APPEND Set pointer to end of file prior to each write. O_CREAT If the file exists, this has no effect. Otherwise, the file is created using the mode flag. See the next chapter for how to create files and other devices using this flag and other system calls. O_TRUNC If the file exists, length is truncated to 0. O_EXCL If set with O_CREAT, the open will fail if the file exists. The other bits can be "or"d into the flags to modify the I/O access. For example fd = open( file1, O_WRONLY O_CREAT O_TRUNC, 0); opens a file in write only mode (O_WRONLY), creates the file if it does not exist (O_CREAT) and clears out its contents if it does exist (O_TRUNC) CRS Enterprises Ltd 22

23 close() close(fd) int int close(int fd) fd) 0 or or -1-1 Descriptor to to close close Copyright CRS Enterprises Ltd 23 The close system call is used to close an open file descriptor. Close returns 0 on success and -1 on error, with errno set to indicate the error CRS Enterprises Ltd 23

24 read() bytesread = read(fd, &buffer, sizeof(buffer)); int int read(int fd, fd, char *buffer, int int requested) number of of bytes bytes read read -1-1 on on error error 0 on on EOF EOF descriptor buffer buffer to to store store read read characters size size of of buffer buffer filesize filesize = bytes bytes requested requested bytesread bytesread bytes bytes position position Copyright CRS Enterprises Ltd 24 The read system call is used to read data from a file or device. The data is stored in the specified buffer and the number of bytes written to the buffer are returned from the system call. A return value of 0 indicates end of file, and a return value of -1 indicates error (errno set to error code). The number of bytes read will be the number requested, except when the number of bytes left in a file is less than the number requested. When reading from serial lines (terminals), the number read will depend upon the mode of the terminal (see the description of terminals in the next chapter). In the simple case for terminals, a single line of data is read and saved in the buffer (including the terminating newline), unless this would exceed the number of bytes requested. When reading from seeking devices (files), the data is read from the current file position and the file position is incremented by the number of bytes read (ready for the next read). If the descriptor was opened with the O_NDELAY flag set, then reading from device or pipe that has no data available will return immediately with no data read. This situation is not the same as end of file CRS Enterprises Ltd 24

25 write() byteswritten = write(fd, "Message", sizeof("message")); int int write(int fd, fd, char *buf, int int n) n) No. No. of of bytes bytes written written -1-1 on on error error descriptor buffer buffer holding bytes bytes to to write write no. no. of of bytes bytes to to write write Copyright CRS Enterprises Ltd 25 The write system call is used to write data to a file or device. The number of bytes written is returned from the call, unless an error occurred, in which case -1 is returned and errno is set to indicate the error. When writing to seeking devices (files), the data is written at the current file position and the file position is incremented by the number of bytes written. If the O_APPEND flag was set on open, then the file pointer is always reset to the end of the file before the write takes place. Such writes are guaranteed to be atomic CRS Enterprises Ltd 25

26 File Descriptors User Area Open File Table Kernel in memory inodes Terminal file1 file2 Copyright CRS Enterprises Ltd 26 Unix processes can identify files using file descriptors as well as the stream file type (FILE). File descriptors are non-negative integers that are used to index a file-control table local to each process. Standard file descriptors are used for a process's files which are open by default; these are: 0 Standard input. 1 Standard output. 2 Standard error output. Note that the symbolic names stdin, stdout and stderr defined in the stdio.h header file refer to the FILE streams and not to the file descriptors. The implementation of the stream file type is achieved using the lower-level file descriptors. int fileno (FILE *stream) will return the low-level file descriptor associated with a file stream. It is not advisable to intermix stream I/O and the low-level I/O system calls (described next) on the same open file. Open file descriptors remain open across exec and fork system calls (described in a later chapter). This permits a child process to inherit a parent's open files (typically standard input, output and error) CRS Enterprises Ltd 26

27 fileno() and fdopen() Process Area fp FILE* FILE Run Time Library Buffer User Area fd pointer Kernel Area inode FILE* FILE* fp; fp; int int fd; fd; fp fp = fopen( file1, r+ ); r+ ); fd fd = fileno(fp); FILE* FILE* fp; fp; int int fd; fd; fd fd = open( file1, O_RDWR); fp fp = fdopen(fd); Copyright CRS Enterprises Ltd 27 Unix processes can identify files using file descriptors as well as the stream file type (FILE). File descriptors are non-negative integers that are used to index a file-control table local to each process. Standard file descriptors are used for a process's files which are open by default; these are: 0 Standard input. 1 Standard output. 2 Standard error output. Note that the symbolic names stdin, stdout and stderr defined in the stdio.h header file refer to the FILE streams and not to the file descriptors. The implementation of the stream file type is achieved using the lower-level file descriptors. int fileno (FILE *stream) will return the low-level file descriptor associated with a file stream. It is not advisable to intermix stream I/O and the low-level I/O system calls (described next) on the same open file. Open file descriptors remain open across exec and fork system calls (described in a later chapter). This permits a child process to inherit a parent's open files (typically standard input, output and error) CRS Enterprises Ltd 27

28 Opening Files User Area Kernel vnodes stdin stdout stderr O_RDWR 2113 bytes Unix File System modes = -rw-r----- owner = 200 group = 40 atime = 24 July bytes 4 5 Unix File System modes = -rwxr--r-- file descriptor block O_RDONLY 609 bytes owner = 101 group = 40 atime = 25 July bytes Copyright CRS Enterprises Ltd 28 Each process has a file-descriptor table that contains information about every file the process has open and the flags associated with the file. If the process was run from a standard shell, it would almost certainly have the first three file descriptors allocated to stdin, stdout and stderr. Each process also has an open file table. This table contains a pointer to the vnode structure, flags to indicate the mode in which the file was opened and the current offset in the file for read() and write() operations. The kernel maintains a vnode table for every open file. This table is shared by all processes. The table indicates the file-system type (e.g. Unix, NFS, PC), a pointer to the inode of the file (Unix file systems only) and the size of the file. It is important to realize that if several processes open the same file, then they share the vnode structure, but have their own open file tables. This enables different processes to maintain different file offsets, so that they can access different parts of a file simultaneously CRS Enterprises Ltd 28

29 Example void void PrintFile(void) {{ int int fd, fd, bytesread; char char buffer[bufsize]; fd fd = open("file1", O_RDONLY, 0); 0); if if (fd (fd < 0) 0) perror("open:"), exit(1); exit(1); while(1) {{ bytesread = read(fd read(fd,buffer,,buffer, BUFSIZE); if if (n (n <= <= 0) 0) break; break; write write (1, (1, buffer, buffer, bytesread); }} close close (fd); (fd); }} Copyright CRS Enterprises Ltd 29 This is a simple function to print a file to standard output. It makes no allowances for read errors. This function copies the data verbatim, with no breaking up of long lines CRS Enterprises Ltd 29

30 stat() int stat (char *path, struct stat *statbuf) int fstat(int fd, struct stat *statbuf) stat("/etc/passwd", &inodeinfo); 0 or or -1-1 Pointer Pointer to to buffer buffer to to be be filled filled Copyright CRS Enterprises Ltd 30 The stat and fstat system calls return (in the stat record) details of the appropriate file. This information is extracted from the inode for the file. fstat uses an open file descriptor, whereas stat uses a full filename (the file may or may not be open by this process). Stat and fstat return zero on success, -1 on error CRS Enterprises Ltd 30

31 I/O - Status Information struct struct stat stat {{ ushortst_mode; file file mode mode ino_t ino_t st_ino; st_ino; inode inode number short short st_nlink; number of of links links ushortst_uid; user user id id ushortst_gid; group group id id off_t off_t st_size; file file size size in in bytes bytes time_t time_tst_atime; time time of of last last access access time_t time_tst_mtime; time time of of last last modification time_t time_tst_ctime; time time of of last last status status change change }} Copyright CRS Enterprises Ltd 31 The stat data structure contains fields derived from the inode information. Some of the more obvious and interesting fields are shown on the slide. The st_mode field defines the status and protection flags for the file. Most of the other fields should be self explanatory. The time fields define time in terms of seconds measured from 00:00 GMT, Jan 1, This is the standard Unix time-stamping mechanism (see the header file <time.h> for routines such as time, localtime, asctime, etc.). The special data types are defined in the header file #include <sys/types.h> CRS Enterprises Ltd 31

32 st_mode file type s s t r w x r w x r w x regular directory special symbolic link file pipe permissions socket character special block special normal file permissions Copyright CRS Enterprises Ltd 32 Probably the most important field in the stat structure is the st_mode field. This has type mode_t, usually an unsigned short, with each bit representing one characteristic of the object. The mode field indicates two main features of the object: The type of object, i.e. file, directory or one of the special file types such as device, pipe or socket. The access permissions for the object, including any setuid or setgid information. The mode field is most easily analyzed with a collection of defined constants and macros from the include file <sys/stat.h>. The next slides show these in more detail CRS Enterprises Ltd 32

33 Inode Type void void FindOutFileType(void) { struct struct stat stat buffer; buffer; } stat("file1", stat("file1", &buffer); &buffer); if if (S_ISREG (S_ISREG (buffer.st_mode) (buffer.st_mode) printf("directory"); if if (S_ISDIR (S_ISDIR (buffer.st_mode) (buffer.st_mode) printf("regular printf("regular file"); file"); if if (S_ISFIFO (S_ISFIFO (buffer.st_mode) (buffer.st_mode) printf("fifo"); printf("fifo"); if if (S_ISCHR (S_ISCHR (buffer.st_mode) (buffer.st_mode) printf("character printf("character device"); device"); if if (S_ISBLK (S_ISBLK (buffer.st_mode) (buffer.st_mode) printf("block printf("block device"); device"); Copyright CRS Enterprises Ltd 33 An inode's object type is determined by examining its mode field, using facilities provided in the include file <sys/stat.h>: S_ISREG(mode) S_ISDIR(mode) S_ISCHR(mode) S_ISBLK(mode) S_ISFIFO(mode) S_ISLNK(mode) S_ISSOCK(mode) evaluates to TRUE (>0) if mode describes a file is TRUE for a directory is TRUE for a character-device special file is TRUE for a block-device special file is TRUE for a named pipe is TRUE for a symbolic link is TRUE for a socket CRS Enterprises Ltd 33

34 Access Permissions void void FilePermissionsForUser(void) { struct struct stat stat buffer; buffer; int int rwx; rwx; char char permissions[] permissions[] = "---"; "---"; stat stat ( /home/user100/.profile, &buffer); &buffer); rwx rwx = buffer.st_mode buffer.st_mode & (S_IRWXU S_IRWXG S_IRWXO); if if (rwx (rwx & S_IRUSR) S_IRUSR) permissions[0] permissions[0] = 'r'; 'r'; if if (rwx (rwx & S_IWUSR) S_IWUSR) permissions[1] permissions[1] = 'w'; 'w'; if if (rwx (rwx & S_IXUSR) S_IXUSR) permissions[2] permissions[2] = 'x'; 'x'; } printf("user printf("user permissions: permissions: %s %s \n", \n", permissions); permissions); Copyright CRS Enterprises Ltd 34 The access permissions for the object are obtained using a set of defined constants. They can be used to test individual permissions or to obtain sets of permissions. (mode & S_IRWXU) (mode & S_IRWXG) (mode & S_IRWXO) (mode & S_IRUSR) (mode & S_IWUSR) (mode & S_IXUSR) (mode & S_IRGRP) (mode & S_IWGRP) (mode & S_IXGRP) (mode & S_IROTH) (mode & S_IWOTH) (mode & S_IXOTH) Some extra features can also be tested, i.e.: (mode & S_ISUID) (mode & S_ISGID) (mode & S_IVTX) generates the rwx permissions for the owner generates the permissions for the object's group generates the permissions for other users is TRUE if the owner has read permission is TRUE if the owner has write permission is TRUE if the owner has execute permission is TRUE if the group has read permission is TRUE if the group has write permission is TRUE if the group has execute permission is TRUE if other users have read permission is TRUE if other users have write permission is TRUE if other users have execute permission is TRUE if the set-uid bit is set on the inode is TRUE if the set-gid bit is set is TRUE if the sticky bit is set CRS Enterprises Ltd 34

35 3 Copyright CRS Enterprises Ltd CRS Enterprises Ltd 35

36 Files and Directories 3 Copyright CRS Enterprises Ltd CRS Enterprises Ltd 36

37 Files and Directories System calls for files and directories Library calls for navigating directories Effective User Id Hard Links Symbolic Links Copyright CRS Enterprises Ltd 37 This chapter describes system calls used to manage files and directories. Routines to create files and devices are described, as are the general routines for renaming and removing files and changing access permissions. The system independent run time library routines for navigating directories is presented. The role of effective and real user ids is also discussed CRS Enterprises Ltd 37

38 System calls for Files int unlink (const char *path) int rename (const char *old, const char *new) int chmod (char *name, int mode) int chown (char *name, int owner, int group) long lseek (int fd, long offset, int origin) Copyright CRS Enterprises Ltd 38 The unlink() system call is used to remove a file's entry from a directory. The link reference count in the file's inode is decremented, and if this reaches zero, the file is deleted. The rename() system call renames the specified file, which can be any form of file including directories and special files. The chmod() system call changes the permission flags for the specified file. The set user id and set group id bits and sticky bit can be modified in addition to the access-control bits. Only the superuser and owner of a file can change the access flags. The chown() system call changes the named file's owner and group to the specified ids. Only the superuser or file owner may change the ownership or group ids. The lseek() system call sets the file position for the next read or write on the file represented by descriptor fd. Example calls: unlink ("file1"); rename ("OldFileName", "NewFileName"); chmod ("file1", 0600); chown ("file1", 100, 50); lseek (fd, L, SEEK_SET); CRS Enterprises Ltd 38

39 Real and Effective User user5canreadfile = access ("file1", R_OK); root executing /usr/bin/passwd user5 executing /usr/bin/ksh Copyright CRS Enterprises Ltd 39 The access() system call is the only system call that checks file access against real user id. All other system calls respect the effective user id. A process s effective user id is the same as its real user id unless the executable file used to load the process into memory has its set user bit set. In the example shown above, user5 executes the ksh, passwd and ksh executables in order. When the passwd executable is executed, because it is owned by root and has its set user bit is set, user5 s effective user id is set to root. The ksh programs do not have set user bit set and therefore run with effective user id set to user5. While passwd is executing as root, it has permissions to modify any given file. However, the access() call can be used to check if user5 would normally have permission to modify the given file; the stat() call cannot be used because it respects effective user id. The access system call returns zero if the requested access to the file is permitted. Requested file access is determined by the lowest three bits of the mode word, which correspond to the read (040), write (020) and execute (010) permission bits. These can be represented mnemonically using the defined constants: R_OK W_OK X_OK F_OK exists. The file can be read by the current process. The file can be written by the current process. The file can be executed by the current process. All intermediate directories in the path can be read and the file CRS Enterprises Ltd 39

40 The Role of the Directory Directory file1 file file2 file file3 file softlink softlink Inode links=3 stat() Data Block abcdefghijk read() Inode Data Block symbolic link lstat() file2 readlink() Copyright CRS Enterprises Ltd 40 The main job of a directory is to associate a name with an inode. A directory is a special type of file, that contains a table, mapping names onto inodes. When you access a file by name, Unix looks up the directory containing the file and finds out the inode number. It can then retrieve the inode from the inode area of the disk, and find out all it needs to know about the file (or directory). A directory contains two types of links to inodes: hard links and symbolic links. In this example we create a file called file1 (a hard link) and then create two further hard links using the Unix commands print ABCDEFGHIJKLM > file1 ln file1 file2 ln file1 file3 As you can see from the diagram, file1, file2 and file3 all share the same inode. In reality, there is one file with 3 names. We can create a symbolic link (soft link) using the Unix command ln -s file2 softlink Note that the symbolic link uses a different inode from before. commands cat file1 cat file2 cat file3 cat softlink all print the same information. Nevertheless, the CRS Enterprises Ltd 40 The system calls for extracting information from hard links are stat() and read()/write(). Symbolic links have their own system calls: lstat() and readlink().

41 System calls for Directories int int mkdir mkdir (const char char *path, int int mode) mode) int int rmdir rmdir (const char char *path) int int chdir chdir (const char char *path) int int link link (const char char *old, *old, const const char char *new) *new) int int symlink (const char char *old, *old, const const char char *new) *new) int int lstat lstat (const char char *name, struct stat stat *statbuf) int int readlink (const char char *name, void void *buffer, int int bufsize) Copyright CRS Enterprises Ltd 41 Directories are created with the mkdir() system call. When a directory is created, the entries for "." and ".." created at the same time. The link reference count for a new directory will be set to two; one for its primary name and one for the "." link created within the directory. The parent's directory link count will also be incremented by one for the new directory entry. Empty directories are removed with rmdir(). The entries for "." and ".." are unlinked before the directory itself is deleted. The chdir() system call sets the current working directory to the specified pathname. The directory must exist. The link() system call creates additional filenames for an inode. A file's inode keeps a reference count of the number of links or names it is known by. A file is only deleted, and its data blocks reclaimed, when its reference count falls to zero and no process has the file open. A symbolic link is created with the symlink() system call. System calls such as open() and stat(), when used on a symbolic link, automatically traverse the link. Symbolic links may point across file systems (partitions). The system call lstat() is provided to extract the information stored in the symbolic link's inode. The readlink() system call is provided to give access to the name string stored in the symbolic link. Example calls: int mkdir (const char *path, int mode) int rmdir (const char *path) CRS Enterprises Ltd 41 int chdir (const char *path) int link (const char *old, const char *new)

42 Accessing Directory Contents d_name d_ino pdir pdirent DIR* struct dirent* DIR file1 file2 file3 file4 file5 file struct struct dirent dirent *dentp; *dentp; DIR DIR *dp; *dp; dp dp = opendir("/usr"); opendir("/usr"); struct dirent do do dentp dentp = readdir(dp); readdir(dp); while(dentp while(dentp!=!= NULL) NULL) Copyright CRS Enterprises Ltd 42 The directory include file dirent.h defines a number of library routines which simplify the interface to directories. The routines described on the next slide provide a common file-system-independent interface to directories. Their use is recommended in preference to opening and reading directories using the simple I/O operations open(), read(), lseek() and close(). The directory structure struct dirent is defined according to the underlying file system type. Two of the most common directory layouts are shown below: Fixed Length Filenames struct dirent { } ino_t char d_ino; d_name[14]; Variable Length Filenames struct dirent { } ino_t u_short d char d_ino; namlen; d_name[]; Programs written using the directory routines and the common data fields d_ino and d_name will be portable CRS Enterprises Ltd 42

43 Library Calls for Directories DIR* opendir(char* name) void closedir(dir* dirp) struct dirent* readdir(dir* dirp) void rewinddir(dir* dirp) long telldir(dir *dirp) void seekdir(dir *dirp, long loc) Copyright CRS Enterprises Ltd 43 The opendir() call opens a directory for reading and returns a pointer to a directory stream control structure. This structure is allocated by the run time library code. The closedir() call closes a directory and frees the memory allocated for the directory stream structure. The readdir() call reads the next valid entry from the directory and returns a pointer to a dirent structure allocated within the DIR stream data. At the end of the directory, readdir() returns NULL. There is only one dirent structure in the DIR data, so subsequent calls to the readdir() library routine overwrite the data in this record. The rewinddir() call resets a directory stream so that a directory's contents can be rescanned. The telldir() call remembers the current location within a directory. The seekdir() call is used to position to a previously-remembered location. Example calls: dirptr = opendir("/tmp/dir1"); closedir (dirptr) direntptr = readdir(dirptr); rewinddir(dirptr) offset = telldir(dirptr) seekdir(dirptr, offset) CRS Enterprises Ltd 43

44 Example struct struct stat stat statbuffer; struct struct dirent dirent *dentp; *dentp; DIR DIR *dp; *dp; dp dp = opendir("/usr"); do do {{ dentp dentp = readdir(dp); filename = dentp->d_name; stat(filename, &statbuffer); if if (statbuffer.st_size > 8192) 8192) printf("%s is is larger larger than than 8K\n", 8K\n", filename); }} while(dentp!=!= NULL) NULL) Copyright CRS Enterprises Ltd 44 In this example we navigate through all entries in the directory /usr. As each filename is determined we use the stat() system call to check if the file is larger than 8K in size. The names of all such files are printed on standard output CRS Enterprises Ltd 44

45 4 Copyright CRS Enterprises Ltd CRS Enterprises Ltd 45

46 Signals 4 Copyright CRS Enterprises Ltd CRS Enterprises Ltd 46

47 Signals What is a signal? An indication to a process that an event has occurred A "software interrupt" How are signals sent to a process? By other processes By the kernel In response to a hardware condition In response to operating system conditions Copyright CRS Enterprises Ltd 47 Signals are used to inform processes when asynchronous events occur, i.e. a process does not have to explicitly wait for the event or look to see if the event has occurred. This has led to signals often being known as "software interrupts". Signals can be sent to a process by another process using the kill() system call. They may also be sent to a process by the kernel in response to some condition which has arisen, either in the kernel itself or in the underlying hardware. For example, if a process attempts a divide-by-zero operation, the hardware in the arithmetic or floating-point unit will normally generate some form of exception. This is detected by the kernel, which arranges for the process to be sent a signal notifying it of an arithmetic exception. Certain keys on the keyboard also cause a process to be sent a signal. For example, hitting the DEL or Ctrl-C key causes the current process to be sent an "interrupt" signal, which normally causes the process to terminate. Modern Unix implementations define upwards of 30 different signals, the majority of which are common across all versions. The set of signals available is part of the virtual machine definition, which allows Unix to present a consistent interface to programmers across a wide range of hardware platforms. It is not necessary to be aware of the different hardware interrupt conditions, as they will be dealt with in the kernel, which translates them into the appropriate signals CRS Enterprises Ltd 47

48 Some Common Signals Signal Source / Reason Normal Effect SIGINT ^c or DEL key Terminate SIGQUIT ^\ key Terminate with core SIGBUS Hardware data alignment fault Terminate with core SIGALRM Kernel timer (alarm()) Terminate SIGFPE Arithmetic exception Terminate with core SIGKILL kill -9 Terminate SIGUSR1 User defined Ignored SIGTERM Software termination signal Terminate Copyright CRS Enterprises Ltd 48 The slide illustrates some of the more common signals, together with the reasons why they are sent to a process and the normal effect on the process. If you want a signal to produce a different effect from the normal effect, you must write a signal handler function. Signals are represented by small integer numbers. However, for ease of use, there are defined constants that can be used equivalently. These values are defined in <signal.h>. You cannot create your own signals if you have a POSIX.1 system You are allowed to define additional signals if you are using the POSIX.4 real time extensions CRS Enterprises Ltd 48

49 Dealing with Signals What actions can a process take upon receipt of a signal? Default Action Requires no action by process Usually terminates process Ignore SIGKILL, SIGSTOP cannot be ignored Catch Arrange for user-defined function to be called SIGKILL, SIGSTOP cannot be caught Copyright CRS Enterprises Ltd 49 When a process receives a signal, there are three courses of action open to it: Default Ignore Catch Every signal has a "default action" associated with it. If no other action is taken by a process, then the default action for the signal is taken by a process on receipt of that signal. In most cases, the default action is to terminate the process. Many signals, particularly those associated with exceptional conditions, also cause a core image to be generated. The core image may then be analyzed with debugging tools to see what caused the exception. A process can choose to ignore a signal. In this case, the process will not be informed when it has been sent the signal. It is possible to ignore all signals, except SIGKILL and SIGSTOP. A process may "catch" a signal and execute a specific routine when it receives the signal. The function to be executed is known as the signal handler. It is possible to catch all signals, except SIGKILL and SIGSTOP CRS Enterprises Ltd 49

50 Writing a Signal Handler void void SIGHUP_Handler (int (int signalnumber) {{ write write (1, (1,"SIGHUP received\n", 16); 16); }} void void SIGINT_Handler (int (int signalnumber) {{ write write (1, (1,"SIGINT received\n", 16); 16); }} void void SIGQUIT_Handler (int (int signalnumber) {{ write write (1, (1,"SIGQUIT received\n", 17); 17); }} Copyright CRS Enterprises Ltd 50 The slide shows sample signal-handler routines for SIGHUP, SIGINT and SIGQUIT. Each handler uses the write() system call to print a simple message. Do not use printf() inside a signal handler unless you are using a thread safe C Run Time Library; the standard implementation of printf it is not reentrant. When a signal-handler routine is called, it is always passed the signal number of the signal that occurred. This allows the same routine to be installed for multiple signals and allows the routine to know which signal caused it to be called. Some of the signals that are caused through hardware conditions also provide further information. For example, the SIGFPE signal may have been caused by divide by zero, overflow or underflow. A signal handler for SIGFPE will normally be able to access this information and work out which actual condition caused the signal. However, this facility is implementation dependent and will vary according to the system (hardware and version of Unix) being used. When a handler routine returns, execution of the process will continue from the instruction where it was interrupted CRS Enterprises Ltd 50

51 Unix Signal Model sigaction() sigpending() sigprocmask() main() main() {{ /* /* code code */ */ /* /* code code */ */ }} procmask handlera() handlera() {{ /* /* handle handle signal signal */ */ }} handlerb() handlerb() {{ /* /* handle handle signal signal */ */ }} handler mask Copyright CRS Enterprises Ltd 51 The Unix signal model is quite complicated. The process's code consists of a main thread plus several signal handlers. The main thread is executed until a signal is delivered. As soon as a signal arrives, execution of the main thread is suspended and the appropriate handler thread executed. Each signal handler is protected from delivery of unwanted signals by defining a signal mask. Each handler thread has its own mask which you can define to BLOCK selected signals. For example, the main thread could block SIGINT and SIGHUP and one of the handlers block SIGUSR1. If one of the blocked signals is sent to your process, it is not delivered to the process until the mask is changed to allow the signal through. Such signals are deemed pending signals. Each handler routine and signal mask is registered with the kernel by calling the sigaction() function. This function transfers the handler address and mask to a table in the process s user area. The kernel uses this table when delivering a signal to determine which thread to run. The main thread s signal mask is set by calls to sigprocmask() CRS Enterprises Ltd 51

52 Signal Masks Process Signal Mask List of signals to be blocked by the process Blocked signals are left pending Other signals are delivered to the process Handler Signal Mask List of signals blocked while in the handler Current signal automatically blocked Mask only effective while executing handler Copyright CRS Enterprises Ltd 52 The process signal mask defines which signals are blocked by the process. If a signal is blocked, the kernel will ensure it is not delivered (and hence its signal handler is not called). Such a signal is left pending. A process is free to change its process signal mask at any time; this may cause pending signals to be delivered. The kernel remembers any pending signals and if the process signal mask is changed will immediately deliver any pending signals that have been unblocked. The signal handler mask defines additional signals to be blocked while a handler is executing. Without the mechanism it would be very difficult to handle several signals delivered in quick succession. The signal being handled is automatically blocked in its own handler. This behaviour can be changed if you wish by setting the flags word of sigaction CRS Enterprises Ltd 52

53 Installing a Signal Handler sigaction (signalnumber, &, & ); struct struct sigaction {{ void void (*sa_handler)(); sigset_t sa_mask; int int sa_flags; }} handler mask flags handler mask flags New New settings Old Old settings Copyright CRS Enterprises Ltd 53 Signal handlers may be installed using the sigaction() system call. The key parameters in the sigaction() call are the two sigaction structures. Their elements are shown in the slide. The first field is the address of the signal handler; SIG_IGN (ignore signal) and SIG_DFL (default handler) are valid as well as a user-defined function. The second field is a mask of signals to be blocked while the handler is executing. The third field allows special flags to be be set. Either of the two sigaction parameters in a call to sigaction() may be NULL. Set the old setting to NULL if you are not interested in the value being replaced. If the new setting is NULL, then the routine provides a way of examining the current signal action without changing it CRS Enterprises Ltd 53

54 Defining Signal Masks sigset_t sigemptyset(&mask) sigaddset(&mask, SIGUSR1) sigaddset(&mask, SIGUSR2) sigset_t sigfillset(&mask) sigdelset(&mask, SIGUSR1) sigdelset(&mask, SIGUSR2) Copyright CRS Enterprises Ltd 54 Signal masks provide a way of restricting the types of signals delivered to a process. A process can set up an empty mask (no signals masked) using the sigemptyset() macro and then mask out signals one at a time using sigaddset(). Alternatively, a process can set up a filled mask (all signals masked) using the sigfillset() macro and then remove signals from the mask one at a time using sigdelset() CRS Enterprises Ltd 54

55 Other System Calls sigprocmask sigpending sigismember pause(); (options, &newmask, &oldmask); (&pendingmask); (&pendingmask, SIGHUP); Copyright CRS Enterprises Ltd 55 A process may set its process signal mask using the sigprocmask() function. A process normally sets the process signal mask soon after it fires up. The process mask can be changed at any time by a further call to sigprocmask(). The first parameter to sigprocmask() can be one of the following: SIG_BLOCK signal mask. The signals in the second parameter are added to the current SIG_UNBLOCK The signals in the second parameter are removed from the current signal mask, i.e. they are unblocked. SIG_SETMASK The signal mask is set explicitly to the parameter set. The process mask is sometimes used to protect critical regions of code from being interrupted by a particular signal. The mask is set upon entry to the critical section and the cleared on leaving. If the unwanted signal is generated during execution of the critical code, it will be left pending and do no harm. It will be delivered as soon as the mask is reset. If there are any signals pending for the process and the call to sigprocmask() unblocks the signal(s), then at least one of the signals will be delivered to the process before the routine returns. A process can examine the signals pending by using the sigpending() and sigismember() functions. The pause() function puts a process to sleep until a signal (any signal) is delivered to the process. This is preferable to entering a tight infinite loop and thereby wasting CPU time CRS Enterprises Ltd 55

56 Using Signal Masks sigset_t newmask, pendingmask; void void main main (void) (void) {{ sigemptyset (&newmask); sigaddset (&newmask, SIGHUP); sigaddset (&newmask, SIGTRAP) sigprocmask (SIG_SETMASK, &newmask, NULL); NULL); pause(); /* /* wait wait for for signal signal */ */ sigpending (&pendingmask); if if (sigismember (&pendingmask, SIGHUP)) printf printf ("SIGHUP is is pending"); }} Copyright CRS Enterprises Ltd 56 In this example a process sets its process signal mask to block SIGHUP and SIGTRAP. The process is not interested in its old process mask and therefore passes NULL as the third parameter to sigprocmask(). The process then puts itself to sleep and waiting for a signal other than SIGHUP or SIGTRAP. When pause() returns (some other signal has been delivered), the process is awakened by the kernel and the appropriate signal handler called. SIGHUP and SIGTRAP are still blocked. To find out if either of these signals are pending, the process calls sigpending(). This routine returns a mask containing a list of all pending signals. Calling sigismember() checks for an individual pending signal (SIGHUP) CRS Enterprises Ltd 56

57 sigsuspend() Process is suspended until any signal is delivered atomic version of sigprocmask() and pause() int int sigsuspend (sigset_t *sigmask); -1-1 always always returned errno errno set set to to EINTR EINTR signal signal mask mask while while process is is suspended Copyright CRS Enterprises Ltd 57 sigsuspend() allows a process to be suspended while waiting for a signal to arrive. First, however, the routine changes the process mask. The process is resumed as soon as a signal is delivered. sigsuspend() is an atomic version of sigprocmask() and pause(). It is used to avoid race conditions: a race condition is where one of two conditions could occur dependent on timing considerations. Suppose that in the previous example we are only expecting one signal to be delivered after we change the process mask. This signal will wake us up from the pause() call. But what if this signal is delivered too early; just before we call pause()? In that case the signal will be handled as usual, but after we subsequently call pause() we will sleep forever because no more signals will get delivered. This is a good example of a race condition CRS Enterprises Ltd 57

58 signal() oldhandler = signal(signalnumber, newhandler) Previous handler or or -1-1 Signal Signal number Pointer Pointer to to Handler Copyright CRS Enterprises Ltd 58 The signal() system call was the original method of installing signal handlers before signal masks were introduced. All new code should use the more flexible sigaction() call. You need to be aware of the signal() system call because it is still found in a great many older applications CRS Enterprises Ltd 58

59 Sending a Signal sent to process 700 kill( 700, signalnumber) kill( -700,signalNumber) kill( 0, 0, signalnumber) sent to all processes in group 700 sent to all processes in our process group Copyright CRS Enterprises Ltd 59 A process can send a signal using the kill() system call. Kill is a misnomer; the kill signal was the original signal implemented in early versions of Unix and hence the naming of the system call. kill() allows a process to send a signal to a different process. For fairly obvious security reasons, a process with an effective user id of anything other than superuser may only send signals to processes with the same effective user id. Under normal circumstances, kill() will signal the specified process id. There are some special cases, however. pid users effect > 0 all The signal is sent to process pid. 0 all The signal is sent to all processes in the sender's process group. -1 not root The signal is sent to all processes whose real uid is the same as the sender's effective uid. -1 root The signal is sent to all user processes (i.e. all processes except pid 0 and 1). < -1 all The signal is sent to all processes in the process group abs(pid). If the signal number parameter to kill() is 0, then no signal is sent, but the validity of the process id argument is checked. This checks if a particular process exists CRS Enterprises Ltd 59

60 Signals Example struct struct sigaction new; new; sigset_t emptymask, procmask; void void void Handler (int (int id) id) { void InstallHandler(void) { { if if (id (id == == SIGUSR1) write write (1, (1,"SIGUSR1", 7); { 7); sigemptyset if if (id (id == == SIGUSR2) write write (1, (1,"SIGUSR2", 7); (&emptymask); 7); } new.sa_handler } = Handler; Handler; new.sa_mask = emptymask; void void main(void) { new.sa_flags { = 0; 0; printf("%d\n", getpid()); sigaction(sigusr1,&new, NULL); NULL); InstallHandler(); sigaction(sigusr2,&new, NULL); NULL); sigemptyset (&procmask); } } sigaddset (&procmask, SIGINT); sigprocmask (SIG_SETMASK, &procmask, NULL); NULL); /* /* wait wait for for signals signals */ */ while while (1) (1) pause(); }} Copyright CRS Enterprises Ltd 60 The idea in this code fragment is to use one signal handler for SIGUSR1 and SIGUSR2 and block delivery of SIGINT signals. This allows us to see how the sigaction() and sigprocmask() system calls work. The sigaction() call installs the signal handler along with its signal mask and optional flags. We have chosen to use an empty mask (no signals blocked) and no flags. Since we are not interested in the state of the previous handler, we have used a NULL pointer as the third argument. The sigprocmask() call allows us to define which signals are to be blocked in the current process. We have chosen to block the SIGINT signal. Once the process has called pause(), we can send SIGUSR1 and SIGUSR2 signals to the process. The pause() system call will return and the handler will be called. If we try to send a SIGINT signal, the kernel blocks the signal and pause() does not return CRS Enterprises Ltd 60