Kernel issue???

when the child process ends before the parent hence orphan process gets adopted by "init" process but in kernels from 4.4+ i have observed that the parent PID of the orphan is the PID of some "user" process as shown below:

1330 ?        Ss     0:00 /sbin/upstart --user

Here PPID of orphan returned is 1330 which is not the PID of init which is 1.

Am of the opinion that after some kernel patches the basic init adoption has been changed, and is now adopted by some USER process..

Pls share ur thoughts..

post ur kernel version>?? @adeshagarwal02

I think this is kernel dependent because in latest versions ppid of orphan is 1122 which is a user process here . It doesn't go to INIT .

Anyone found Process Control Block
path:
struct task_struct

                                                            wait() system call      
If a parent terminates before child, then child will be orphan. So we can manage parent process in such way that it will wait until child process terminates. for that purpose we will follow these steps:-

Step 1. exit(exit_code) :- Define exit code for child and parent and send exit code of child to parent by using exit.

Step 2. wait:- Pause parent using wait call. It will force parent to wait until child terminates.

Step 3. Check WIFEXITED:- It will check if child terminate normally or not , If yes then  parent will resume and  execute child Termination Section.

Step 4. Fetch Code WEXITSTATUS:- We can fetch exit code of the terminated child process.

Note:- Earlier we were getting child ppid 1. Means child was adopted by init and pid of init usually 1.In this case of wait() system call we can see child ppid remains same even after parent finishes his task, because parent is waiting for child exit code.

@somanshu765

"struct task_struct" can be found at the following location for the sched.h file

/usr/src/linux-headers-4.4.0-78-generic/include/linux$ vim sched.h
(For ubuntu user -- my machine)

/usr/src/kernels/version/linux/include

or

/usr/include

(For fedora users)

[things may vary slightly]

or we can use "grep task_struct *.h" in the folder containing header file to get sched.h

• Using a fork() statement we can duplicate a process and thus create its child process.

• The child process shares the stack segment with the parent process.

• The child process has no process context of its own, it uses one from the parent process.

• It has its own process control block (struct task_struct - kernel data structure) where it stores its PID,PPID and unique Program counter set.

• The program counter for the child starts from the fork() statement in the code segment that initiated the child process.

• The part of the code segment from fork() onwards (included) runs parallel with the on going parent's code segment, no statements prior to fork() are executed for the child, however the child does get all the access to the declared variables etc due to having a shared segment.

• Copy on write -- A copy of the variable in the shared segment is created when any write operation takes place, hence we get 2 variable having the same logical address but a different physical address.

• fork() sys call returns the PID of the created child, which is the next available PID after parent's PID on successful creation of child process,otherwise it returns '-1'.

• The value returned is of pid_t type i.e. kernel datatype.

• As the fork statement is also executed for the child process and it returns '0' thus preventing further grand children process of the parent process.
  

RCS File to show orphan process :

head    1.1;
access;
symbols;
locks
        xenial-xerus:1.1; strict;
comment @ * @;


1.1
date    2017.05.25.17.34.34;    author xenial-xerus;    state Exp;
branches;
next    ;


desc
@orphan shown
@


1.1
log
@Initial revision
@
text
@#include<stdio.h>
#include<stdlib.h>
#include<unistd.h>
#include<sys/types.h>

void main()
{

        printf("\n%s : Begin    PID: %d  PPID: %d  \n",__FILE__,getpid(),getppid());
        
        pid_t ret;

        int v;
        printf("\nHello !! \n");
        
        ret=fork();
        
        printf("\nReturned value: %d\n",ret);

     switch(ret)
        {
       
                case -1:
                        perror("fork failed");
                        exit(EXIT_FAILURE);

                case  0:
                        printf("\n Child \n");
                        v=15;  
                        break;
                default:
                        printf("\n Parent \n");
                        v=5;
                       
        }
       
        for(int i=0;i<v;i++)
        {
                printf("\n PID : %d     PPID : %d",getpid(),getppid());
                sleep(1);
        }


        printf("\nHello World..!!\n");

        printf("\n%s : End     PID: %d  PPID: %d  \n",__FILE__,getpid(),getppid());
}


@
                                                                                                                                    74,1          Bot

                                                                                                                                    1,1           Top

                                                           atexit()

atexit function registers the function which will be called at termination of a 

programme , it returns 0 on success and non zero in case of any error.

Prototype:- int atexit(void (*function)(void));

Steps

Step1: define a function in program.

Step2: Register that function in main using atexit(&myfunc). 

Note:- atexit() takes function without arguments like:- void myfunc();

For using argument type function there is another function on_exit

                 int on_exit (void (*function)(int, void*),void *arg);

Note:- exit() is totally different, It terminates a process. But atexit() 

always executes before termination of a process/program.

Process 2

head    1.1;
access;
symbols;
locks; strict;
comment    @ * @;


1.1
date    2017.05.26.13.20.32;    author root;    state Exp;
branches;
next    ;


desc
@Process 2
@


1.1
log
@Initial revision
@
text
@#include<stdio.h>
#include<stdlib.h>
#include<fcntl.h>
#include<unistd.h>
#include<sys/types.h>
#include<string.h>

int main(int argc,char *argv[])

{
//    printf("Hello\n");
    int rfd,ret,count;
    char rbuff[19];
    rfd=atoi(argv[1]);
    printf("rfd : %d\n",rfd);
    sleep(10);
    count=read(rfd,rbuff,18);
    rbuff[count]='\0';
    printf("The things read are: %s\n",rbuff);
    return 0;
}
   
@

                                                    This  code is for Process Hijack 

#include<stdio.h>
#include<stdlib.h>
#include<unistd.h>
#include<sys/types.h>
#include<fcntl.h>
int main(int argc, char *argv[],char *envp[])
{
    int sfd,w;
    char buff[atoi(argv[2])];
    w=atoi(argv[2]);
    sfd=atoi(argv[1]);
    lseek(sfd,0,SEEK_SET);
    read(sfd,buff,w);
    printf("Start:Pid:%d,Ppid:%d,file dis:%d\n",getpid(),getppid(),sfd);
    printf("I killed you\n");
    printf("END:Pid:%d,Ppid:%d,file dis :%d\n",getpid(),getppid(),sfd);
    printf("%s\n",buff);
    return 0;
}

Process Replacement or Process Hijacking 

(B)Demonstration of execl()

• They are like temporary storage locations/buffers that enable more than one process to communicate with each other via data sharing
• They are part of our actual file system, unlike pipes, but the data flows in it only during runtime and there is no scope of saving data to it once the connections are lost, unlike file IO operations
• unlike pipes they can also be accessed by different processes that are not inter related
• File operations are almost same as normal FILE IO, unlike pipes, but definitely not all are permitted as they are not files, but temporary buffers
• Block on open : when only the read or only the write connector is present, it prevents any further operation until both connectors are present or it could be file opened via O_RDWR permissions flag
• Block on read: when the FIFO is empty, we need to write some data, else reading is blocked
• Block on write: when FIFO is completely full, first we need to empty it via reading characters, else no further writing will be allowed.
• FIFO is basically is a circular queue
• it is a named pipe (can be said that)
• header file inclusion: 

1. sys/types.h
2. sys/stat.h
   

  sched.h struct task_struct

Basic concepts for pipes :

• A pipe is a means of communication between related processes
• This allows us to transmit and receive data between various processes that have a common ancestor
• Now we mean to make a system wherein a server can get the data from the requesting client, process that data and accordingly,send that data to appropriate client for required manipulation
• Then this client, after manipulation sends the data to the server which further sends it back to the requesting client.
  

Algorithm steps :

• Here we will make pipes as follows : 1 for each client, 2 pipes for processing clients (adders, subtractor, etc),  1 common pipe for result writing.Hence 4 pipes, thus an integer array of size 4*2 = 8 file descriptors.
  
• The server forks a child process, that is hijaked/replaced by a requesting client proccess (execl), here we send the write file descriptors of pipe1 (for the client will write data to the server) and read file descriptors of pipe4( for the client will read the result wriiten by server from pipe4 )
• This requesting client scans for inputs and writes to pipe1 using the write file descriptor, then tries to read from pipe4 via read file descriptors but as of now, the pipe is empty hence it stays on a block ("Block on read").
• Meanwhile the server will call the req_processing(int *fds) func. that reads from pipe1, here *fds is the array of fds passed, total 8 fds for 4 pipes ( 1 pipe for each client, 1 common pipe for result writing to client, 2 pipes for the processing clients(adders, subtractors, etc))
  
• After reading, the appropriate client is called for required manipulation on this data, this data gotten from requesting client is written to pipe2 and a child process is forked, sending the read file descriptor of pipe2 and write file descriptor of pipe3 to the client (suppose an adder).
• Simultaneously the req_processing() writes using the write file descriptors to pipe2, and adder reads it, then after manipulating the data , the adder writes it to the pipe3 using write file descriptor, and now the req_processing (parent of adder) reads it and returns it to the calling func, that is server.
• Server now has the manipulated form of data, which it writes to the pipe4.
• Now we have to note, that till now the requesting  client is on "block on read", thus as the data is written to the pipe4 by server, it comes out of the block and successfully reads the required data.
  

        Done!!

Why we need semaphores in Client- Server communications??
[Synchronization issue in FIFO/pipes ]

• when a process is trying to open a FIFO, it can only do so if the other end of FIFO is opened , otherwise it shall face "block on open", a FIFO can be opened only when it has both a writer and a reader.
• When both are present, a FIFO can be opened, but still its open only for writing when it is empty "block on read", when something is written to it only then can it be made available to read from.
• Using this technique, we have multiple clients, that try to communicate with FIFO's.
• When the all try to write to the FIFO, all go on "block on open", untill the FIFO is opened from reader side (server) as well, but as soon as it is open, they all get simultaneous access to the same FIFO, hence all try to write into it together, which has good probability of messing up the input, as the server can only read a limited no of bytes, hence we get synchronization issues.
• Thus we need a mechanism, where only a particular client can write to the server, and similarly read back the result from the server, without any other conflicting process issues.
• The same is the problem with reading from clients because even if, we may get a particular client to input the whole data required by server, there is very high chance that while sending back the data, the result may be received by any of the clients, and not just the required ones, as the server uses the same FIFO for sending data to all clients, other wise we would be requiring large number of FIFOs, which is practically feasible.
  

        Thus we need semaphores.

                                                   For a Orphan Child Ctrl+Z will never work.

An orphan process is a computer process whose parent process has finished or terminated, and it remains running itself.

So I think Ctrl +Z always taken by Parent and Parent is no more here in case of Orphan. I tried to terminate Orphan process with Ctrl + Z but it is not taking . It is getting terminated with Ctrl + C.

Implemented single binary semaphore on the Client-Server communication using FIFOs [rectifying the previous issues and Alogorithm] :

• Earlier, as mentioned above, we saw issues related to synchronization between multiple clients trying to reach out for a common resource (FIFO in this case).
• This issue is solved as of now by applying the semaphore over the critical part of our code.
• The semaphore is a synchronization technique used to control operations that require multiple processes accessing a shared resource, simultaneously
• The mechanism is such that we place the portion of our code, that has such issues, in the critical section, that is bounded by a semaphore.
• The process that reached the semaphore earliest shall be allowed to enter the following critical region of our code, simultaneously changing the value of the semaphore variable, which will then prevent the other processes from entering the critical section of our code.
• Here, we place the P() (wait) semaphore function before the client's open() call t the common FIFO, and the the V() (release semaphore) function after we have done our manipulation and are willing to read from another client.
• P() will allow a process to pass only if the semaphore value is the default value, that we set in the beginning, else the process has to wait for the same.
• V() when called will reset the semaphore value to the initially set value, hence allowing the waiting process to pass from P() and enter into the critical section of code.
• Hence now we will be preventing two or more clients from writing into the common FIFO for all, instead everything will be happening sequentially.

Some basic function calls and required headers :

       #include <sys/types.h>
       #include <sys/ipc.h>
       #include <sys/sem.h>

Each semaphore in a System V semaphore set has the following associated values:

       unsigned short  semval;   /* semaphore value */
       unsigned short  semzcnt;  /* # waiting for zero */
       unsigned short  semncnt;  /* # waiting for increase */
       pid_t           sempid;   /* PID of process that last
                                        modified semaphore value */

•  int semget(key_t key, int nsems, int semflg);

• int semop(int semid, struct sembuf *sops, size_t nsops);

      The elements of sembuf structure :

      unsigned short sem_num;  /* semaphore number */
      short          sem_op;   /* semaphore operation */
      short          sem_flg;  /* operation flags */

• int semctl(int semid, int semnum, int cmd, ...);

         The calling program must define this union as follows:

           union semun {
               int              val;    /* Value for SETVAL */
               struct semid_ds *buf;    /* Buffer for IPC_STAT, IPC_SET */
               unsigned short  *array;  /* Array for GETALL, SETALL */
               struct seminfo  *__buf;  /* Buffer for IPC_INFO
                                           (Linux-specific) */
           };

                How to block a Signal during a Signal Handler running
        struct sigaction act;   
        act.sa_sigaction = &ouch; // ouch is signal handler :- Prototype is :- void ouch (int sig, siginfo_t *siginfo)
        sigemptyset(&act.sa_mask); // clear old blocked signal
        sigaddset(&act.sa_mask,SIGQUIT); // Blocking Ctrl+backslash during handler SIGINT running
        act.sa_flags = SA_SIGINFO; // set flag to get info        
        sigaction(SIGINT, &act, 0);//Register signal

typedef struct {
    int si_signo;
    int si_code;
    union sigval si_value;
    int si_errno;
    pid_t si_pid;
    uid_t si_uid;
    void *si_addr;
    int si_status;
    int si_band;
} siginfo_t;

we can also check inside handler ouch about info using siginfo_t *siginfo
Example:-
void ouch (int sig, siginfo_t *siginfo)
{
        int i=1;
        while(i)
        {
                printf("\n Ouch I Got signal %d\n",sig);
                printf("Enter i : \n");
                scanf("%d",&i);
                if( siginfo->si_code == SI_KERNEL )
                        printf ("KERNEL  PID: %d, CODE: %d\n", siginfo->si_pid, siginfo->si_code);
                else
                        printf("USER\n");
        }
}

Misconception:

There is an ambiguity between binary semaphore and mutex. We might have come across that a mutex is binary semaphore. But they are not!The purpose of mutex and semaphore are different. May be, due to
similarity in their implementation a mutex would be referred as binary semaphore.

A mutex is locking mechanism used to synchronize access to a resource. Only one task (can be a
thread or process based on OS abstraction) can acquire the mutex.It means there is ownership associated with mutex, and only the owner can release the lock (mutex).

Semaphore is signaling mechanism .

        Using Semaphore to overcome the problem of multiple client to server

Why to use semaphore if problem is resolved by using signals?
Previously  we used signal for multiple client, from which we are able to resolve problem but not in efficient way because whenever multiple client process comes into the critical section of code all of the sudden trying to access the share resources simultaneously ,because of this  request are been overlap of one client to the another client because of this some of the clients which are overlap are not getting accurate results.

What is critical section? 
Those section of codes that access shared data, which actually perform data update and need to execute exclusively are called critical section

What Semaphore will do?
Semaphore will insure that in critical section of code there should be a  single process to have exclusive access to resources.

How semaphore will work ?
Semaphore is a special variable (sv) that takes only whole positive number and upon which only two operation are allowed i.e. 'wait' and 'signal'
P: For wait operation 
V: For signal operation
This two operation  P and V are put before (P Operation only )and after(V Operation only) critical section the semaphore variable (sv) is initially set to a positive whole number, at this stage semaphore will allow one of the client process to enter the critical section and simultaneously P (wait Operation)decrease the positive number by 1,Semaphore will wait  now, when the client process which is in critical section,got entertain  and trying to leave V( signal operation) will  increase the sv  by 1 ,and then another process enter the critical section this will repeat same way until all the process are been entertained.

                                                                   Advanced signal Handling (sigaction)

why to use Advanced signal Handling?
In previous signals, we are not able to send argument to the handler. Advance signal is providing facility of sending argument to the handler. by using advance signal  we can block the other signals to sig pending buffer at a time when handler of other signal is running.

Syntax:
int sigaction(int sig,const struct sigaction *act,struct sigaction *oact);
where act is new signal and oact is old signals

sigaction will return 0 for success and -1 for error

 sigaction structure contains

• void (*)(int) sa_handler /* for handler*/
  
• sigset_t sa_mask  /* signal to be block*/
• int sa_flag /* for action modifier  */
  

sa_handler pointer to a function is called when signal sig is rescued

sa_mark will specifies a set of signal mask before the sa_handler fuction called. These are set of signals that are blocked and won't be delivered to the process

Important functions

int sigaddset(sigset_t *set,int sig_no);/* will add the specified signal  sig_no to signal set*/

int sigemptyset(sigset_t *set);/* will empty the signal set*/

int sigfillset(sigset_t *set);/*internalise the signal set to contain all defined signal set*/ 

int sigdelset(sigset_t *set,int sig_no);/* will delete the specified signal  sig_no from signal set*/

int sigprocmask(int how,const struct sigaction *act,struct sigaction *oact);

sigprocmask can change the process signal mask in a number of ways according to the how argument 

int how can be  flowing

• SIG_BLOCK          /*for the signal in set is added to signal mask*/
  
• SIG_SETMASK     /*for the signal mask is set from set */
• SIG_UNBLOCK     /*for the signal in set are removed from signal mask */

Message Queues : A named pipe without any open/close issues

• message queues are similar to FIFO, a named pipe, except that they are not supposed to be opened or closed as an when required.
• they are different from pipe or FIFO as here data is sent "block by block" and not "byte by byte"
• the maximum value of a block can be MSGMAX bytes, where as the maximum size of queue can be MSGMNB.
• A block of data sent at once has 2 attributes, 1.) Type  2.) Payload (message)
  
• here type can be any positive whole number that is used for identifying the text to be read by the reader
• reader can be conditioned to read a particular type or types from the queue
• there is no open/close, hence no concept of "block on open" unlike FIFOs
• however, there is "block on read" and "block on write" , when the queue is vacant for the required type specified and full, respectively, which however can be overridden by setting the IPC_NOWAIT flag.
• If a value is read from somewhere in the middle, an empty space will be created, which will be the one that writer usees for writing, as first vacant space will be treated as the last space.

The Shared Memory concept :

• its the concept that allows multiple different processes two access the same memory location.
• this is same as using a pointer, to a particular memory location, every process gets logical address for the same memory location (its physical address).
• every process that has this logical address has the capability of accessing that area in the memory depending upon permissions set by the process that created the shared memory
• the creating process creates shared memory and defines the size for it.
• shmget() function returns the "shmid" for the shared space, each process calling this gets the  same identifier.
• but this space is still not visible in the address space for the process unless the process attaches itself to the "shmid" returned by the shmget().
• shmat() is used to attach to a shared space by returning a void pointer, that can be typecasted to any valid pointer type.
• similarly shmdt() is used to detach from a previously attached shared memory
• one can check for the number of attached processes to any shared memory segment by typing "ipcs" as shown below by the "nattch":

------ Shared Memory Segments --------

key        shmid      owner      perms      bytes      nattch     status     
0x00000000 1277952    dexterous  600        77824      2          dest        
0x00000000 229377     dexterous  600        524288     2          dest        
0x00000000 786435     dexterous  600        3850240    2          dest        
0x00000000 753668     dexterous  600        3850240    2          dest        
0x00000000 950277     dexterous  600        1708032    2          dest        
0x00000000 1048582    dexterous  600        57344      2          dest        
0x00000000 1179655    dexterous  600        36864      2          dest        
0x00000000 1114120    dexterous  600        196608     2          dest        
0x00000000 1146889    dexterous  600        196608     2          dest        
0x00000000 1245194    dexterous  600        1708032    2          dest     

                                           Syntax for Semaphore

Step 1: Include header files
#include<sys/sem.h>

Step 2: Get semaphore ID  using

int semget(key_t key, int num_sems, int sem_flags); will return sem_id (semaphore id )

Where
Key is the number supplied by user
num_sems is the number of semaphore required this almost always 1
sem_flag it is a flag to open function (provides Permissions ) usually can be used as IPC_CREATE|0666

Step 3: Get semop for wait and signal
int semop(int sem_id ,structure sembuf *sem_ops, size_t num_sem_ops);

this will return 0 and -1 for success and Failure
sem_id is the return of semget function
sembuf *sem_ops is a structure shown below
struct sembuf{
short sem_num;// it is an index of semaphore usually it is zero for (one semapore)
short sem_op;// it operation to increase or decrease to the semaphore value by one (1 for increase and -1 for decrease )
short sem_flg;// usually SEM_UNDO
};
sem_ops index number (usually zero)

Step 4: For directional control

int semctl(int sem_id, int sem_num,int command,...);

sem_id is the return of semget function
int sem_num is an union defined below
union semun{
int val;// Usually 1
struct semid_ds *buff;
unsigned short *arry;
};
int command will be SETVAL to initialize semaphore or IPC_RMD to remove semaphore

Current project : Multi-threaded Client-Server Communication

So far I have been able to accomplish the following:

• Every time a client approaches the server, the server creates a thread in order to communicate with the client, contrary to our previous project "Client-Server Comm.using processes" where we deal only with processes.
• This thread creates 2 new threads for that client.
• the first threaded created reads the input from the client and communicates with the required processing client in order to get the result.
• This thread end with a pthread_exit(<static address of the result structure to pass>).
• Meanwhile, the second thread is waiting for the first to end and gets the results to the client
• Now the parent thread waits for the main thread created by server to end.

Why we need threads ??


1. Responsiveness: If the process is divided into multiple
threads, if one thread completed its execution, then its output can be
immediately responded.

2. Faster context switch: Context switch time between threads is less compared to process context switch. Process context switch is more overhead for CPU.

3. Effective Utilization of Multiprocessor system: If we
have multiple threads in a single process, then we can schedule multiple
threads on multiple processor. This will make process execution faster.

4. Resource sharing: Resources like code, data and file can be shared among all threads within a process.However, stack and registers can’t be shared among the threads. Each thread have its own stack and registers.

5. Communication: Communication between multiple thread is
easier as thread shares common address space. while in process we have
to follow some specific communication technique for communication
between two process.

6. Enhanced Throughput of the system: If process is divided
into multiple threads and each thread function is considered as one
job, then the number of jobs completed per unit time is increased. Thus,
increasing the throughput of the system.

Conditions for a Deadlock:

Deadlock can arise if following four conditions hold simultaneously (Necessary Conditions)

• Mutual Exclusion: One or more than one resource are non-sharable (Only one process can use at a time)
• Hold and Wait: A process is holding at least one resource and waiting for resources.
• No Preemption: A resource cannot be taken from a process unless the process releases the resource.
• Circular Wait: A set of processes are waiting for each other in circular form.
  
  

Understanding Hard and Soft (Symbolic) links in Linux: