Text preview for : unit6USP.pdf part of USP unit6 unit6



Back to : unit6USP.pdf | Home

UNIX SYSTEM PROGRAMMING

UNIT ­VI
6.1 Introduction Signals
Objectives : Basically signals are software interrupts. All most all the application programs need to deal with signals. Signals provide a way of handling asynchronous events: a user at a terminal typing the interrupt key to stop a program or the next program in a pipeline terminating ahead of time. Signals have been provided since the early versions of the UNIX System, but the signal model provided with systems such as Version 7 was not reliable. Signals could get lost, and it was difficult for a process to turn off selected signals when executing critical regions of code. Both 4.3BSD and SVR3 made changes to the signal model, adding what are called reliable signals. In this chapter user start with an overview of signals and a description of what each signal is normally used for. Then we look at the problems with earlier implementations.

6.2 Introduction Signal Concepts
First, every signal has a name. These names all begin with the three characters SIG. For example, SIGABRT is the abort signal that is generated when a process calls the abort function. SIGALRM is the alarm signal that is generated when the timer set by the alarm function goes off. Version 7 had 15 different signals; SVR4 and 4.4BSD both have 31 different signals. FreeBSD 5.2.1, Mac OS X 10.3, and Linux 2.4.22 support 31 different signals, whereas Solaris 9 supports 38 different signals. Both Linux and Solaris, however, support additional application-defined signals as real-time extensions (the real-time extensions in POSIX aren't covered in this book The below table show the default action for the most signals is to terminate the proces.

Table 6.1 Unix System Signals
Name SIGABRT SIGALRM SIGBUS SIGCANCEL SIGCHLD SIGCONT SIGEMT SIGFPE SIGFREEZE SIGHUP SIGILL SIGINFO SIGINT Description abnormal termination (abort) timer expired (alarm) hardware fault threads library internal use change in status of child continue stopped process hardware fault arithmetic exception checkpoint freeze hangup illegal instruction status request from keyboard terminal interrupt character Default action terminate+core terminate terminate+core ignore ignore continue/ignore terminate+core terminate+core ignore terminate terminate+core ignore terminate

Page 1

UNIX SYSTEM PROGRAMMING
SIGIO asynchronous I/O terminate/ignore SIGIOT hardware fault terminate+core SIGKILL termination terminate SIGLWP threads library internal use ignore SIGPIPE write to pipe with no readers terminate SIGPOLL poll able event (poll) terminate SIGPROF profiling time alarm (set timer) terminate SIGPWR power fail/restart terminate/ignore SIGQUIT terminal quit character terminate+core SIGSEGV invalid memory reference terminate+core SIGSTKFLT coprocessor stack fault terminate SIGSTOP stop stop process SIGSYS invalid system call terminate+core SIGTERM termination terminate SIGTHAW checkpoint thaw ignore SIGTRAP hardware fault terminate+core SIGTSTP terminal stop character stop process SIGTTIN background read from control tty stop process SIGTTOU background write to control tty stop process SIGURG urgent condition (sockets) ignore SIGUSR1 user-defined signal terminate SIGUSR2 user-defined signal terminate SIGVTALRM virtual time alarm (setitimer) terminate SIGWAITING threads library internal use ignore SIGWINCH terminal window size change ignore SIGXCPU CPU limit exceeded (setrlimit) terminate+core/ignore When a signal is sent to a process, it is pending on the process to handle it. The process can react to pending signals in one of three ways: 1. Accept the default action of the signal, which for most signals will terminate the process. [ SIG_DFL] 2. Ignore the signal. The signal will be discarded and it has no affect whatsoever on the recipient process. [SIG_IGN] 3. Invoke a user-defined function. The function is known as a signal handler routine and the signal is said to be caught when this function is called. [Function Pointer] We now describe a few of these signals in more detail. SIGABRT This signal is generated by calling the abort function and process terminates abnormally. SIGALRM This signal is generated when a timer set with the alarm function expires. This signal is also generated when an interval timer set by the setitimer(2) function expires. SIGBUS This indicates an implementation-defined hardware fault. Implementations usually generate this signal on certain types of memory faults.

Page 2

UNIX SYSTEM PROGRAMMING
SIGCANCEL This signal is used internally by the Solaris threads library. It is not meant for general use. SIGCHLD Whenever a process terminates or stops, the SIGCHLD signal is sent to the parent. By default, this signal is ignored, so the parent must catch this signal if it wants to be notified whenever a child's status changes. The normal action in the signalcatching function is to call one of the wait functions to fetch the child's process ID and termination status. SIGCHLD for backward compatibility. SIGCONT This job-control signal is sent to a stopped process when it is continued. The default action is to continue a stopped process, but to ignore the signal if the process wasn't stopped. A full-screen editor, for example, might catch this signal and use the signal handler to make a note to redraw the terminal screen. SIGEMT This indicates an implementation-defined hardware fault.

6.3 The Unix Kernel Support of Signals
When a signal is generated for a process, the kernel will set the corresponding signal flag in the process table slot of the recipient process. If the recipient process is asleep, the kernel will awaken the process by scheduling it. When the recipient process runs, the kernel will check the process U-area that contains an array of signal handling specifications. If array entry contains a zero value, the process will accept the default action of the signal. If array entry contains a 1 value, the process will ignore the signal and kernel will discard it. If array entry contains any other value, it is used as the function pointer for a user-defined signal handler routine.

6.3 The Signal Function
The function prototype of the signal API is: The simplest interface to the signal features of the UNIX System is the signal function. #include void (*signal(int signo, void (*func)(int)))(int); Returns: previous disposition of signal (see following) if OK, SIG_ERR on error The formal argument of the API are: sig_no is a signal identifier like SIGINT or SIGTERM. The handler argument is the function pointer of a user-defined signal handler function. The following example attempts to catch the SIGTERM signal, ignores the SIGINT signal, and accepts the default action of the SIGSEGV signal. The pause API suspends the calling process until it is interrupted by a signal and the corresponding signal handler does a return:

Page 3

UNIX SYSTEM PROGRAMMING
#include #include /*signal handler function*/ void catch_sig(int sig_num) { signal (sig_num,catch_sig); cout<<"catch_sig:"<
SIGNAL MASK
A process initially inherits the parent's signal mask when it is created, but any pending signals for the parent process are not passed on. A process may query or set its signal mask via the sigprocmask API: #include int sigprocmask(int cmd, const sigset_t *new_mask, sigset_t *old_mask); Returns: 0 if OK, 1 on error The new_mask argument defines a set of signals to be set or reset in a calling process signal mask, and the cmd argument specifies how the new_mask value is to be used by the API. The possible values of cmd and the corresponding use of the new_mask value are:
Cmd value SIG_SETMASK Meaning Overrides the calling process signal mask with the value specified in the new_mask argument. SIG_BLOCK Adds the signals specified in the new_mask argument to the calling process signal mask. SIG_UNBLOCK Removes the signals specified in the new_mask argument from the calling process signal mask. SIG_BLOCK Adds the signals specified in the new_mask argument to the calling process signal mask.

If the actual argument to new_mask argument is a NULL pointer, the cmd argument will be ignored, and the current process signal mask will not be altered. If the actual argument to old_mask is a NULL pointer, no previous signal mask will be returned.
Page 4

UNIX SYSTEM PROGRAMMING
The sigset_t contains a collection of bit flags. The BSD UNIX and POSIX.1 define a set of API known as sigsetops functions: #include int sigemptyset (sigset_t* sigmask); int sigaddset (sigset_t* sigmask, const int sig_num); int sigdelset (sigset_t* sigmask, const int sig_num); int sigfillset (sigset_t* sigmask); int sigismember (const sigset_t* sigmask, const int sig_num);

The sigemptyset API clears all signal flags in the sigmask argument. The sigaddset API sets the flag corresponding to the signal_num signal in the sigmask argument. The sigdelset API clears the flag corresponding to the signal_num signal in the sigmask argument. The sigfillset API sets all the signal flags in the sigmask argument. [ all the above functions return 0 if OK, -1 on error ] The sigismember API returns 1 if flag is set, 0 if not set and -1 if the call fails. The following example checks whether the SIGINT signal is present in a process signal mask and adds it to the mask if it is not there. #include #include int main() { sigset_t sigmask; sigemptyset(&sigmask); /*initialise set*/ if(sigprocmask(0,0,&sigmask)==-1) /*get current signal mask*/ { perror("sigprocmask"); exit(1); } else sigaddset(&sigmask,SIGINT); /*set SIGINT flag*/ sigdelset(&sigmask, SIGSEGV); /*clear SIGSEGV flag*/ if(sigprocmask(SIG_SETMASK,&sigmask,0)==-1) perror("sigprocmask"); } A process can query which signals are pending for it via the sigpending API: #include int sigpending(sigset_t* sigmask); Returns 0 if OK, -1 if fails

The sigpending API can be useful to find out whether one or more signals are pending for a process and to set up special signal handling methods for these signals before the
Page 5

UNIX SYSTEM PROGRAMMING
process calls the sigprocmask API to unblock them. The following example reports to the console whether the SIGTERM signal is pending for the process: #include #include #include int main() { sigset_t sigmask; sigemptyset(&sigmask); if(sigpending(&sigmask)==-1) perror("sigpending"); else cout<<"SIGTERM signal is:"<< (sigismember(&sigmask,SIGTERM) ? "Set" : "No Set") << endl; } In addition to the above, UNIX also supports following APIs for signal mask manipulation: #include
int sighold(int signal_num); int sigrelse(int signal_num); int sigignore(int signal_num); int sigpause(int signal_num);

SIGACTION
The sigaction API blocks the signal it is catching allowing a process to specify additional signals to be blocked when the API is handling a signal. The sigaction API prototype is: #include int sigaction(int signal_num, struct sigaction* action, struct sigaction* old_action); Returns: 0 if OK, 1 on error The struct sigaction data type is defined in the header as: struct sigaction { void (*sa_handler)(int); sigset_t sa_mask; int sa_flag; } The following program illustrates the uses of sigaction:
Page 6

UNIX SYSTEM PROGRAMMING
#include #include #include #include void callme(int sig_num) { cout<<"catch signal:"<
THE SIGCHLD SIGNAL AND THE waitpid API
When a child process terminates or stops, the kernel will generate a SIGCHLD signal to its parent process. Depending on how the parent sets up the handling of the SIGCHLD signal, different events may occur: 1. Parent accepts the default action of the SIGCHLD signal: SIGCHLD does not terminate the parent process. Parent process will be awakened. API will return the child's exit status and process ID to the parent. Kernel will clear up the Process Table slot allocated for the child process. Parent process can call the waitpid API repeatedly to wait for each child it created. 2. Parent ignores the SIGCHLD signal: SIGCHLD signal will be discarded. Parent will not be disturbed even if it is executing the waitpid system call. If the parent calls the waitpid API, the API will suspend the parent until all its child processes have terminated. Child process table slots will be cleared up by the kernel. API will return a -1 value to the parent process. 3. Process catches the SIGCHLD signal: The signal handler function will be called in the parent process whenever a child process terminates.

Page 7

UNIX SYSTEM PROGRAMMING
If the SIGCHLD arrives while the parent process is executing the waitpid system call, the waitpid API may be restarted to collect the child exit status and clear its process table slots. Depending on parent setup, the API may be aborted and child process table slot not freed.

THE sigsetjmp AND siglongjmp APIs The function prototypes of the APIs are: #include int sigsetjmp(sigjmp_buf env, int savemask); int siglongjmp(sigjmp_buf env, int val);

The sigsetjmp and siglongjmp are created to support signal mask processing. Specifically, it is implementation-dependent on whether a process signal mask is saved and restored when it invokes the setjmp and longjmp APIs respectively. The only difference between these functions and the setjmp and longjmp functions is that sigsetjmp has an additional argument. If savemask is nonzero, then sigsetjmp also saves the current signal mask of the process in env. When siglongjmp is called, if the env argument was saved by a call to sigsetjmp with a nonzero savemask, then siglongjmp restores the saved signal mask. The siglongjmp API is usually called from user-defined signal handling functions. This is because a process signal mask is modified when a signal handler is called, and siglongjmp should be called to ensure the process signal mask is restored properly when "jumping out" from a signal handling function. The following program illustrates the uses of sigsetjmp and siglongjmp APIs. #include #include #include #include #include sigjmp_buf env; void callme(int sig_num) { cout<< "catch signal:" <
Page 8

UNIX SYSTEM PROGRAMMING
sigemptyset(&action.sa_mask); sigaddset(&action.sa_mask,SIGSEGV); action.sa_handler=(void(*)())callme; action.sa_flags=0;

if(sigaction(SIGINT,&action,&old_action)==-1) perror("sigaction"); if(sigsetjmp(env,1)!=0) { cerr<<"return from signal interruption"; return 0; } else cerr<<"return from first time sigsetjmp is called"; pause();

}

KILL
A process can send a signal to a related process via the kill API. This is a simple means of inter-process communication or control. The function prototype of the API is: #include int kill(pid_t pid, int signal_num); Returns: 0 on success, -1 on failure. The signal_num argument is the integer value of a signal to be sent to one or more processes designated by pid. The possible values of pid and its use by the kill API are: pid > 0 pid == 0 pid < 0 pid == 1 The signal is sent to the process whose process ID is pid. The signal is sent to all processes whose process group ID equals the process group ID of the sender and for which the sender has permission to send the signal. The signal is sent to all processes whose process group ID equals the absolute value of pid and for which the sender has permission to send the signal. The signal is sent to all processes on the system for which the sender has permission to send the signal

Page 9

UNIX SYSTEM PROGRAMMING
The following program illustrates the implementation of the UNIX kill command using the kill API: #include #include #include #include #include int main(int argc,char** argv) { int pid, sig = SIGTERM; if(argc==3) { if(sscanf(argv[1],"%d",&sig)!=1) { cerr<<"invalid number:" << argv[1] << endl; return -1; } argv++,argc--; } while(--argc>0) if(sscanf(*++argv, "%d", &pid)==1) { if(kill(pid,sig)==-1) perror("kill"); } Else cerr<<"invalid pid:" << argv[0] < ] ...... Where signal_num can be an integer number or the symbolic name of a signal. is process ID.

ALARM

The alarm API can be called by a process to request the kernel to send the SIGALRM signal after a certain number of real clock seconds. The function prototype of the API is: #include Unsigned int alarm(unsigned int time_interval); Returns: 0 or number of seconds until previously set alarm

The alarm API can be used to implement the sleep API: #include #include #include void wakeup( ) {;} unsigned int sleep (unsigned int timer )

Page 10

UNIX SYSTEM PROGRAMMING
{ struct sigaction action; action.sa_handler=wakeup; action.sa_flags=0; sigemptyset(&action.sa_mask); if(sigaction(SIGALARM,&action,0)==-1) { perror("sigaction"); return -1; } (void) alarm (timer); (void) pause( ); return 0; }

INTERVAL TIMERS
The interval timer can be used to schedule a process to do some tasks at a fixed time interval, to time the execution of some operations, or to limit the time allowed for the execution of some tasks. The following program illustrates how to set up a real-time clock interval timer using the alarm API: #include #include #include #define INTERVAL 5 void callme(int sig_no) { alarm(INTERVAL); /*do scheduled tasks*/ } int main() { struct sigaction action; sigemptyset(&action.sa_mask); action.sa_handler=(void(*)( )) callme; action.sa_flags=SA_RESTART; if(sigaction(SIGALARM,&action,0)==-1) { perror("sigaction"); return 1; } if(alarm(INTERVAL)==-1) perror("alarm"); else while(1) { /*do normal operation*/ } return 0; }

Page 11

UNIX SYSTEM PROGRAMMING
In addition to alarm API, UNIX also invented the setitimer API, which can be used to define up to three different types of timers in a process: Real time clock timer Timer based on the user time spent by a process Timer based on the total user and system times spent by a process The getitimer API is also defined for users to query the timer values that are set by the setitimer API. The setitimer and getitimer function prototypes are: #include int setitimer(int which, const struct itimerval * val, struct itimerval * old); int getitimer(int which, struct itimerval * old); The which arguments to the above APIs specify which timer to process. Its possible values and the corresponding timer types are

The struct itimerval datatype is defined as: struct itimerval { struct timeval it_value; /*current value*/ struct timeval it_interval; /* time interval*/ }; Example program: #include #include #include #define INTERVAL 5 void callme(int sig_no) { /*do scheduled tasks*/ } int main() { struct itimerval val; struct sigaction action; sigemptyset(&action.sa_mask); action.sa_handler=(void(*)( )) callme; action.sa_flags=SA_RESTART; if(sigaction(SIGALARM,&action,0)==-1)
Page 12

UNIX SYSTEM PROGRAMMING
{
perror("sigaction"); return 1; } val.it_interval.tv_sec =INTERVAL; val.it_interval.tv_usec =0; val.it_value.tv_sec =INTERVAL; val.it_value.tv_usec =0; if(setitimer(ITIMER_REAL, &val , 0)==1) perror("alarm"); else while(1) { /*do normal operation*/ } return 0; }

The setitimer and getitimer APIs return a zero value if they succeed or a -1 value if they fail.

POSIX.1b TIMERS
POSIX.1b defines a set of APIs for interval timer manipulations. The POSIX.1b timers are more flexible and powerful than are the UNIX timers in the following ways: 1. Users may define multiple independent timers per system clock. 2. The timer resolution is in nanoseconds. 3. Users may specify the signal to be raised when a timer expires. 4. The time interval may be specified as either an absolute or a relative time. The POSIX.1b APIs for timer manipulations are: #include #include int timer_create(clockid_t clock, struct sigevent* spec, timer_t* timer_hdrp); int timer_settime(timer_t timer_hdr, int flag, struct itimerspec* val, struct itimerspec* old); int timer_gettime(timer_t timer_hdr, struct itimerspec* old); int timer_getoverrun(timer_t timer_hdr); int timer_delete(timer_t timer_hdr);

Page 13

UNIX SYSTEM PROGRAMMING

DAEMON PROCESSES
INTRODUCTION
Daemons are processes that live for a long time. They are often started when the system is bootstrapped and terminate only when the system is shut down. DAEMON CHARACTERISTICS The 4 important characteristics of daemons are: 1. 2. 3. 4. Daemons run in background. Daemons have super-user privilege. Daemons don't have controlling terminal. Daemons are session and group leaders.

CODING RULES Call umask to set the file mode creation mask to 0. The file mode creation mask that's inherited could be set to deny certain permissions. If the daemon process is going to create files, it may want to set specific permissions. Call fork and have the parent exit. This does several things. First, if the daemon was started as a simple shell command, having the parent terminate makes the shell think that the command is done. Second, the child inherits the process group ID of the parent but gets a new process ID, so we're guaranteed that the child is not a process group leader. Call setsid to create a new session. The process (a) becomes a session leader of a new session, (b) becomes the process group leader of a new process group, and (c) has no controlling terminal. Change the current working directory to the root directory. The current working directory inherited from the parent could be on a mounted file system. Since daemons normally exist until the system is rebooted, if the daemon stays on a mounted file system, that file system cannot be un mounted. Unneeded file descriptors should be closed. This prevents the daemon from holding open any descriptors that it may have inherited from its parent. Some daemons open file descriptors 0, 1, and 2 to /dev/null so that any library routines that try to read from standard input or write to standard output or standard error will have no effect. Since the daemon is not associated with a terminal device, there is nowhere for output to be displayed; nor is there anywhere to receive input from an interactive user. Even if the daemon was started from an interactive session, the daemon runs in the background, and the login session can terminate without affecting the daemon. If other users log in on the same terminal device, we

Page 14

UNIX SYSTEM PROGRAMMING
wouldn't want output from the daemon showing up on the terminal, and the users wouldn't expect their input to be read by the daemon. Example Program: #include #include #include int daemon_initialise( ) { pid_t pid; if (( pid = for() ) < 0) return ­1; else if ( pid != 0) exit(0); /* parent exits */ /* child continues */ setsid( ); chdir("/"); umask(0); return 0; }

ERROR LOGGING
One problem a daemon has is how to handle error messages. It can't simply write to standard error, since it shouldn't have a controlling terminal. We don't want all the daemons writing to the console device, since on many workstations, the console device runs a windowing system. A central daemon error-logging facility is required. There are three ways to generate log messages: 1. Kernel routines can call the log function. These messages can be read by any user process that opens and reads the /dev/klog device. 2. Most user processes (daemons) call the syslog(3) function to generate log messages. This causes the message to be sent to the UNIX domain datagram socket /dev/log. 3. A user process on this host, or on some other host that is connected to this host by a TCP/IP network, can send log messages to UDP port 514. Note that the syslog function never generates these UDP datagram's: they require explicit network programming by the process generating the log message. Normally, the syslogd daemon reads all three forms of log messages. On start-up, this daemon reads a configuration file, usually /etc/syslog.conf, which determines where different classes of messages are to be sent. For example, urgent messages can be sent to the system administrator (if logged in) and printed on the console, whereas warnings may be logged to a file. Our interface to this facility is through the syslog function. #include void openlog(const char *ident, int option, int facility void syslog(int priority, const char *format, ...); void closelog(void); int setlogmask(int maskpri);
Page 15

UNIX SYSTEM PROGRAMMING

INSTANCE DAEMONS
Some daemons are implemented so that only a single copy of the daemon should be running at a time for proper operation. The file and record-locking mechanism provides the basis for one way to ensure that only one copy of a daemon is running. If each daemon creates a file and places a write lock on the entire file, only one such write lock will be allowed to be created. Successive attempts to create write locks will fail, serving as an indication to successive copies of the daemon that another instance is already running. File and record locking provides a convenient mutual-exclusion mechanism. If the daemon obtains a write-lock on an entire file, the lock will be removed automatically if the daemon exits. This simplifies recovery, removing the need for us to clean up from the previous instance of the daemon. PROGRAM:Ensure that only one copy of a daemon is running #include #include #include #include #include #include #include #include #define LOCKFILE "/var/run/daemon.pid" #define LOCKMODE (S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH) extern int lockfile(int); int already_running(void) { int fd; char buf[16]; fd = open(LOCKFILE, O_RDWR|O_CREAT, LOCKMODE); if (fd < 0) { syslog(LOG_ERR, "can't open %s: %s", LOCKFILE, strerror(errno)); exit(1); } if (lockfile(fd) < 0) { if (errno == EACCES || errno == EAGAIN) { close(fd); return(1); } syslog(LOG_ERR, "can't lock %s: %s", LOCKFILE, strerror(errno)); exit(1); } ftruncate(fd, 0);
Page 16

UNIX SYSTEM PROGRAMMING
sprintf(buf, "%ld", (long)getpid()); write(fd, buf, strlen(buf)+1); return(0);

}

DAEMON CONVENTIONS

If the daemon uses a lock file, the file is usually stored in /var/run. Note, however, that the daemon might need superuser permissions to create a file here. The name of the file is usually name.pid, where name is the name of the daemon or the service. For example, the name of the cron daemon's lock file is /var/run/crond.pid. If the daemon supports configuration options, they are usually stored in /etc. The configuration file is named name.conf, where name is the name of the daemon or the name of the service. For example, the configuration for the syslogd daemon is /etc/syslog.conf. Daemons can be started from the command line, but they are usually started from one of the system initialization scripts (/etc/rc* or /etc/init.d/*). If the daemon should be restarted automatically when it exits, we can arrange for init to restart it if we include a respawn entry for it in /etc/inittab. If a daemon has a configuration file, the daemon reads it when it starts, but usually won't look at it again. If an administrator changes the configuration, the daemon would need to be stopped and restarted to account for the configuration changes. To avoid this, some daemons will catch SIGHUP and reread their configuration files when they receive the signal. Since they aren't associated with terminals and are either session leaders without controlling terminals or members of orphaned process groups, daemons have no reason to expect to receive SIGHUP. Thus, they can safely reuse it

CLIENT-SERVER MODEL
In general, a server is a process that waits for a client to contact it, requesting some type of service. In the service being provided by the syslogd server is the logging of an error message. The communication between the client and the server is one-way. The client sends its service request to the server; the server sends nothing back to the client. In the upcoming chapters, we'll see numerous examples of two-way communication between a client and a server. The client sends a request to the server, and the server sends a reply back to the client.

Page 17