Sri Devaraj Urs Educational Trust (R.

)
R. L. JALAPPA INSTITUTE OF TECHNOLOGY
(Approved by AICTE, New Delhi, Affiliated to VTU, Belagavi & Accredited by NAAC “A” Grade)
Kodigehalli, Doddaballapur- 561 203
Department of CS&E (Artificial Intelligence & Machine Learning)

Subject Code: BCS515C

Subject Name: Unix System Programming
Module Number: 05
Name of the Module: Signals and Daemon Processes
Scheme: 2022
Prepared by: Dr. Manjunatha B N
Associate Professor & HoD
Institute Vision
To be a premier Institution by imparting quality Technical education, Professional Training and Research.

Institute Mission
M1: To provide an outstanding Teaching, Learning and Research environment through Innovative
Practices in Quality Education.
M2: Develop Leaders with high level of Professionalism to have career in the Industry, Zeal for Higher
Education, focus on Entrepreneurial and Societal activities.

Department Vision
To empower the students with knowledge and skills to develop the competency in the field of Artificial
Intelligence and Machine Learning.

Department Mission
M1: To craft the students with Novel and Intellectual skills to capability in the field of Artificial
Intelligence and Machine Learning.
M2: To train the students to have Professional career in the field of AI and ML and zeal for Higher Studies
and Research.

PROGRAMME SPECIFIC OUTCOMES (PSOs)

PSO1: Students will have the ability to understand analyse and demonstrate the knowledge of Human
cognition, Artificial Intelligence, Machine Learning in terms of real world problems to meet the challenges
of future.
PSO2: Students will have the knowledge of software, Hardware, Algorithms, Modelling Networking and
Application Development.
PSO3: Students will have the ability to develop computational knowledge using Innovative tools and
techniques to solve problems in the areas related to Machine learning and Artificial Intelligence.

PROGRAMME EDUCATIONAL OBJECTIVES (PEOs)

PEO1: Graduates will have Prospective careers in the field of AI and ML.
PEO2: Graduates will have good Leadership Qualities, Self Learning abilities and zeal for higher studies
and Research.
PEO3: Graduates will follow Ethical Practices and exhibit high level of professionalism by participating
and addressing Technical, Business and Environmental challenges.
Module-5 Unix System Programming

Module – 5
SIGNALS AND DAEMON PROCESSES
Signals are software interrupts. 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
prematurely.

Name Description Default action

SIGABRT abnormal termination (abort) terminate+core

SIGALRM timer expired (alarm) terminate
SIGBUS hardware fault terminate+core
SIGCANCEL threads library internal use ignore
SIGCHLD change in status of child ignore
SIGCONT continue stopped process continue/ignore
SIGEMT hardware fault erminate+core
SIGFPE arithmetic exception terminate+core
SIGFREEZE checkpoint freeze Ignore
SIGHUP hangup terminate
SIGILL illegal instruction terminate+core
SIGINFO status request from keyboard ignore
SIGINT terminal interrupt character terminate
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 pollable event (poll) terminate
SIGPROF profiling time alarm (setitimer) 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
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
SIGXRES resource control exceeded Ignore

Dept., of CS&E(AI & ML), RLJIT Page 1 Dr. Manjunatha B N

Module-5 Unix System Programming

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:
 Accept the default action of the signal, which for most signals will terminate the process.
 Ignore the signal. The signal will be discarded and it has no affect whatsoever on the recipient
process.
 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.

Unix kernel support for signals

 In Unix system version, each entry in the kernel process table slot has an array of signal flags,
one for each defined in the system.
 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.

SIGNAL
The function prototype of the signal API is:
#include <signal.h>
void (*signal(int sig_no, void (*handler)(int)))(int);
The formal argument of the API are: signal_num is a signal identifier like SIGINT or SIGTERM
defined in the <signal.h>.
The handler is the function pointer of a user defined signal handler function. This function should take
an integer formal argument and does not return any value.

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:
#include<iostream.h>

Dept., of CS&E(AI & ML), RLJIT Page 2 Dr. Manjunatha B N

Module-5 Unix System Programming

#include<signal.h>
/*signal handler function*/
void catch_sig(int sig_num)
{
signal (sig_num,catch_sig);
cout<<”catch_sig:”<<sig_num<<endl;
}

/*main function*/
int main()
{
signal(SIGTERM,catch_sig);
signal(SIGINT,SIG_IGN);
signal(SIGSEGV,SIG_DFL);
pause( ); /*wait for a signal interruption*/
}
The SIG_IGN specifies a signal is to be ignored, which means that if the signal is generated to the
process, it will be discarded without any interruption of the process.
The SIG_DFL specifies to accept the default action of a signal.

Signal Mask
Each process in UNIX or POSIX.1 system has signal mask that defines which signals are blocked when
generated to a process.
A blocked signal depends on the recipient process to unblock it and handle it accordingly.
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 <signal.h>
int sigprocmask(int cmd, const sigset_t *new_mask, sigset_t
*old_mask);
The return value of sigprocmask call is zero if it succeeds or -1 if it fails.

Dept., of CS&E(AI & ML), RLJIT Page 3 Dr. Manjunatha B N

Module-5 Unix System Programming

The new_mask defines a set of to be set or reset in a calling process signal mask. cmd specifies how the
new_mask value is to be used by the API. The possible values

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. The old_mask argument is the address of a
sigset_t variable that will be assigned the calling process’s original signal mask prior to a sigprocmask
call. If the actual argument to old_mask is a NULL pointer, no previous signal mask will be returned.
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<stdio.h>
#include<signal.h>
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”);
}

Dept., of CS&E(AI & ML), RLJIT Page 4 Dr. Manjunatha B N

Module-5 Unix System Programming

Sigaction
The sigaction API is a replacement for the signal API in the latest UNIX and POSIX systems.
The sigaction API is called by a process to set up a signal handling method for each signal it wants to
deal with. .
The sigaction API prototype is:
#include<signal.h>
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 <signal.h> header as:
struct sigaction {
void (*sa_handler)(int);
sigset_t sa_mask;
int sa_flag;
}
The sa_handler field can be set to SIG_IGN, SIG_DFL, or a user defined signal handler function.
The sa_mask field specifies additional signals that process wishes to block when it is handling
signal_num signal.
The signal_num argument designates which signal handling action is defined in the action argument.
The previous signal handling method for signal_num will be returned via the old_action argument if it
is not a NULL pointer. If action argument is a NULL pointer, the calling process’s existing signal
handling method for signal_num will be unchanged.

The following program illustrates the uses of

sigaction: #include<iostream.h>
#include<stdio.h>
#include<unistd.h>
#include<signal.h>

void callme(int sig_num)

{
cout<<”catch signal:”<<sig_num<<endl;
}
int main(int argc, char* argv[])

Dept., of CS&E(AI & ML), RLJIT Page 5 Dr. Manjunatha B N

Module-5 Unix System Programming

{
sigset_t sigmask;
struct sigaction action,old_action;
sigemptyset(&sigmask);
if(sigaddset(&sigmask,SIGTERM)==-1||sigprocmask(SIG_SETMASK,&sigmask,0)==-1)
perror(“set signal mask”);
sigemptyset(&action.sa_mask);
sigaddset(&action.sa_mask,SIGSEGV);
action.sa_handler=callme;
action.sa_flags=0;
if(sigaction(SIGINT,&action,&old_action)==-1)
perror(“sigaction”);
pause();
cout<<argv[0]<<”exists\n”;
return 0;
}

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:
 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.
 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.

Dept., of CS&E(AI & ML), RLJIT Page 6 Dr. Manjunatha B N

 Module-5 Unix System Programming

 Process catches the SIGCHLD signal:

 The signal handler function will be called in the parent process whenever a child
process terminates.
 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 <setjmp.h>
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 userdefined 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<iostream.h>

#include<stdio.h>

#include<unistd.h>

#include<signal.h>

#include<setjmp.h>

Dept., of CS&E(AI & ML), RLJIT Page 7 Dr. Manjunatha B N

Module-5 Unix System Programming

sigjmp_buf env;

void callme(int sig_num)

cout<< “catch signal:” <<sig_num <<endl;

siglongjmp(env,2);

int main()

sigset_t sigmask;

struct sigaction action,old_action;

sigemptyset(&sigmask);

if(sigaddset(&sigmask,SIGTERM)==-1)||sigprocmask(SIG_SETMASK,&sigmask,0)==-
1)

perror(“set signal mask”);

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)

Dept., of CS&E(AI & ML), RLJIT Page 8 Dr. Manjunatha B N

Module-5 Unix System Programming

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<signal.h>
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 The signal is sent to the process whose process ID is pid.
pid == 0 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.
pid < 0 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.
pid == 1 The signal is sent to all processes on the system for which the sender has permission to
send the signal.

Dept., of CS&E(AI & ML), RLJIT Page 9 Dr. Manjunatha B N

Module-5 Unix System Programming

The following program illustrates the implementation of the UNIX kill command using the kill API:
#include<iostream.h>
#include<stdio.h>
#include<unistd.h>
#include<string.h>
#include<signal.h>

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] <<endl;
return 0;
}

The UNIX kill command invocation syntax is:

Kill [ -<signal_num> ] <pid>......
Where signal_num can be an integer number or the symbolic name of a signal. <pid> is process ID.

Dept., of CS&E(AI & ML), RLJIT Page 10 Dr. Manjunatha B N

Module-5 Unix System Programming

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<signal.h>
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<signal.h>
#include<stdio.h>
#include<unistd.h>

void wakeup( )
{ ; }

unsigned int sleep (unsigned int timer )

{
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.

Dept., of CS&E(AI & ML), RLJIT Page 11 Dr. Manjunatha B N

Module-5 Unix System Programming

The following program illustrates how to set up a real-time clock interval timer using the alarm API:
#include<stdio.h>
#include<unistd.h>
#include<signal.h>
#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;
}

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

Dept., of CS&E(AI & ML), RLJIT Page 12 Dr. Manjunatha B N

 Module-5 Unix System Programming

 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<sys/time.h>
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*/
};
The setitimer and getitimer APIs return a zero value if they succeed or a -1 value if they fail.

Example program:
#include<stdio.h>
#include<unistd.h>
#include<signal.h>
#define INTERVAL 5
void callme(int sig_no)
{

Dept., of CS&E(AI & ML), RLJIT Page 13 Dr. Manjunatha B N

Module-5 Unix System Programming

/*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)
{
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;
}

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:
 Users may define multiple independent timers per system clock.

Dept., of CS&E(AI & ML), RLJIT Page 14 Dr. Manjunatha B N

 Module-5 Unix System Programming

 The timer resolution is in nanoseconds.

 Users may specify the signal to be raised when a timer expires.
 The time interval may be specified as either an absolute or a relative
time. The POSIX.1b APIs for timer manipulations are:
#include<signal.h> #include<time.h>

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);

DAEMON PROCESSES
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 characteristics of daemons are:
 Daemons run in background.
 Daemons have super-user privilege.
 Daemons don’t have controlling terminal.
 Daemons are session and group leaders

CODING RULES

Dept., of CS&E(AI & ML), RLJIT Page 15 Dr. Manjunatha B N

Module-5 Unix System Programming

Some basic rules to coding a daemon prevent unwanted interactions from happening. We state these
rules and then show a function, daemonize, that implements them.
1. 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.
2. 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.
3. 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.
4. 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 unmounted.
5. Unneeded file descriptors should be closed. This prevents the daemon from holding open any
descriptors that it may have inherited from its parent.
6. 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 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 <unistd,h>
#include <sys/types.h>
#include <fcntl.h>
int daemon_initialise( )
{
pid_t pid;
if (( pid = fork() ) < 0)

Dept., of CS&E(AI & ML), RLJIT Page 16 Dr. Manjunatha B N

Module-5 Unix System Programming

return –1;
else if ( pid != 0)
exit(0);
/* 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:

 Kernel routines can call the log function. These messages can be read by any user process that
opens and reads the /dev/klog device.
 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.

Dept., of CS&E(AI & ML), RLJIT Page 17 Dr. Manjunatha B N

 Module-5 Unix System Programming

 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 datagrams: 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 <syslog.h>
void openlog(const char *ident, int option, int facility); void
syslog(int priority, const char *format, ...);
void closelog(void);
int setlogmask(int maskpri);

Daemon Conventions
Several common conventions are followed by daemons in the UNIX System.
1. If the daemon uses a lock file, het 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.
2. 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.
3. Daemons can be started from het 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.
4. 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

Dept., of CS&E(AI & ML), RLJIT Page 18 Dr. Manjunatha B N

Module-5 Unix System Programming

of orphaned process groups, daemons have no reason to expect to receive SIGHUP. Thus, they can
safely reuse it.

Client Server Model

 A common use for a daemon process is as a server process. We can call the syslogd process a
server that has messages sent to it by user processes (clients) using a UNIX domain datagram
socket.
 In general, a server is a process that waits for a client to contact it, requesting some type of
service. The service being provided by the syslogd server is the logging of an error message.

Assignment Questions
1. Explain the signal concepts
2. Explain sigaction API with demonstrating program.
3. What is signal mask of a process? WAP to check whether the SIGINT signal present in signal
mask.
4. Write a short note on the SIGCHLD signal and the waitpid API
5. Explain the sigsetjmp and siglongjmp Functions with examples.
6. Explain the kill() API and alarm() API?
7. What are daemon processes? Explain daemon characteristics and basic coding rules. Write a
function that can be called from a program that wants to initialize itself as a daemon
8. What is error logging? Explain with a neat diagram the error logging facility for a daemon
process.
9. Write a short note on client server model.

Dept., of CS&E(AI & ML), RLJIT Page 19 Dr. Manjunatha B N