Named Pipe:

1. Create two FIFOs using mkfifo() command.

2. Open one for reading (FIFO1) and other for writing (FIFO2). 3. Send data from client.

4. Wait from data from client and print the same. 3. Semaphore:

Server:

1. Semaphore set is obtained with semget () function with some specific Semaphore key and set value to one.

2. While not reset by client continue else read data from the file written by client.

Client:

1. Semaphore set is obtained with semget () function with servers specific Semaphore key and set value to 1.

2. Write data to the file and reset the semaphore value and break. Test Input:

1. Named Pipe Client:

[root@localhost Programs]# gcc –o client namedclient.c [root@localhost Programs]#. /client hellopictsctr

Named Pipe Server:

[root@localhost Programs]# gcc –o server namedserver.c [root@localhost Programs]#. /server

2. Unnamed Pipe:

[root@localhost Programs]# gcc unnamed.c [root@localhost Programs]# ./a.out

3. Semaphore Client:

[root@localhost Programs]# gcc semclient.c [root@localhost Programs]# ./a.out

Semaphore Server

[root@localhost Programs]# gcc semserver.c [root@localhost Programs]# ./a.out

Test Output:

1. Named Pipe Server:

Half duplex Server: Read from Pipe: hellopictsctr

Half duplex Server: Converting string: HELLOPICTSCTR 2. Unnamed Pipe:

Parent process:

Enter the data to the pipe: hellopictsctr Child process:

Pipe read successfully: hellopictsctr 3. Semaphore Client:

Enter data: hellopictsctr Semaphore Server:

Waiting for clients to update… Updated : hellopisctsctr

Revised On: 22/06/2009

TITLE System Call PROBLEM

STATEMENT /DEFINITION

Using fork system call creates child process, suspend it using wait system call and transfer it into the Zombie state.

OBJECTIVE To understand concept of Zombie state and learn system calls fork and wait.

• To implement fork system call to create child process and transfer it into Zombie state.

S/W PACKAGES AND HARDWARE APPARATUS USED Linux Fedora 4

PC with the configuration as

Pentium IV 1.7 GHz. 128M.B RAM, 40 G.B HDD, 15’’Color Monitor, Keyboard, Mouse

REFERENCES Advanced Unix Programming By Richard Stevans Vijay Mukhi's -The 'c' odyssey UNIX- Gandhi

STEPS Refer to student activity flow chart, theory, algorithm, test input, test output INSTRUCTIONS FOR WRITING JOURNAL Title • Problem Definition • Theory • Algorithm • Source code • compilation steps • Output • Conclusion

Theory:

On Unix and Unix-like computer operating systems, a zombie process or defunct process is a process that has completed execution but still has an entry in the process table, this entry being still needed to allow the process that started the zombie process to read its exit status. The term zombie process derives from the common definition of

zombie—an undead person. In the term's colorful metaphor, the child process has died

but has not yet been reaped.

When a process ends, all of the memory and resources associated with it are deallocated so they can be used by other processes. However, the process's entry in the process table remains. The parent can read the child's exit status by executing the wait system call, at which stage the zombie is removed. The wait call may be executed in sequential code, but it is commonly executed in a handler for the SIGCHLD signal, which the parent is sent whenever a child has died.

After the zombie is removed, its process ID and entry in the process table can then be reused. However, if a parent fails to call wait, the zombie will be left in the process table. In some situations this may be desirable, for example if the parent creates another child process it ensures that it will not be allocated the same process ID. As a special case, under Linux, if the parent explicitly ignores the SIGCHLD (sets the handler to

SIG_IGN, rather than simply ignoring the signal by default), all child exit status information will be discarded and no zombie processes will be left.

A zombie process is not the same as an orphan process. An orphan process is a process that is still executing, but whose parent has died. They don't become zombie processes; instead, they are adopted by init (process ID 1), which waits on its children.

Zombies can be identified in the output from the Unix ps command by the presence of a "Z" in the STAT column. Zombies that exist for more than a short period of time typically indicate a bug in the parent program. As with other leaks, the presence of a few zombies isn't worrisome in itself, but may indicate a problem that would grow serious under heavier loads. Since there is no memory allocated to zombie processes except for the process table entry itself, the primary concern with many zombies is not running out of memory, but rather running out of process ID numbers.

To remove zombies from a system, the SIGCHLD signal can be sent to the parent manually, using the kill command. If the parent process still refuses to reap the zombie, the next step would be to remove the parent process. When a process loses its parent, init

becomes its new parent. Init periodically executes the wait system call to reap any zombies with init as parent.

Algorithm:

1. Include <sys/wait.h>,<sys/types.h> and <unistd.h> along with other header files. 2. Call the fork system call.

3. In the child process print the child process and parent process ID. 4. In the parent process print the parent process ID.

5. Execute the wait () system call in the parent.

6. While executing, programs use the ps command to see the Zombie child.

Test Input: None Test Output:

[root@localhost Programs]# gcc -o zombie zombie.c [root@localhost Programs]# ./zombie

Child process.

PID = 3952 Parent PID = 3951 Parent process.

PID = 3951 //On terminal 2

[root@localhost Programs]# ps -al

F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 0 S 0 3951 3037 0 82 0 - 396 - pts/0 00:00:00 zombie

1 Z 0 3952 3951 0 82 0 - 0 exit pts/0 00:00:00 zomb <defunct> 4 R 0 3953 3099 0 77 0 - 1069 - pts/1 00:00:00 ps

Revised On: 22/06/2009 TITLE File management

PROBLEM STATEMENT /DEFINITION

File management using low level file access system calls such as write,read,open, lseek, fstat

OBJECTIVE To understand and learn system calls read,write,open,lseek,fstat. • To implement above system calls for file management . S/W PACKAGES AND HARDWARE APPARATUS USED Linux Fedora 4

PC with the configuration as

Pentium IV 1.7 GHz. 128M.B RAM, 40 G.B HDD, 15’’Color Monitor, Keyboard, Mouse

REFERENCES The Design of UNIX Operating System by Maurice Bach Vijay Mukhi's -The 'c' odyssey UNIX- Gandhi

STEPS Refer to student activity flow chart, theory, algorithm, test input, test output INSTRUCTIONS FOR WRITING JOURNAL Title • Problem Definition • Theory • Algorithm • Source code • compilation steps • Output • Conclusion

Theory:

Various File access system calls are described below:

1. write (): The write() system call is used to write data to a file or other object identified