Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

What are session leaders, as in ps -d which selects all processes except session leaders?

share|improve this question

3 Answers 3

up vote 23 down vote accepted

In Linux, every process has several IDs associated with it, including:

  • Process ID (PID)

    This is an arbitrary number identifying the process. Every process has a unique ID, but after the process exits and the parent process has retrieved the exit status, the process ID is freed to be reused by a new process.

  • Parent Process ID (PPID)

    This is just the PID of the process that started the process in question.

  • Process Group ID (PGID)

    This is just the PID of the process group leader. If PID == PGID, then this process is a process group leader.

  • Session ID (SID)

    This is just the PID of the session leader. If PID == SID, then this process is a session leader.

Sessions and process groups are just ways to treat a number of related processes as a unit. All the members of a process group always belong to the same session, but a session may have multiple process groups.

Normally, a shell will be a session leader, and every pipeline executed by that shell will be a process group. This is to make it easy to kill the children of a shell when it exits. (See exit(3) for the gory details.)

I don't think there is a special term for a member of a session or process group that isn't the leader.

share|improve this answer
    
Note: Use ps xao pid,ppid,pgid,sid,comm to view these IDs. –  Mike R Aug 8 at 13:27

A session leader is a process where session id == process id. This sounds contrived, but the session id is inherited by child processes. Some operations within UNIX/Linux operate on process sessions, for example, negating the process id when sending to the kill system call or command. The most common use for this is when logging out of a shell. The OS will send kill -HUP -$$, which will send a SIGHUP (hangup) signal to all the processes with the same session id as the shell. When you disown a process, the session id of the process is changed from the shell, so it will not respond to the hangup signal. This is one part of the process to become a daemon process.

Most of the processes called from the window manager/graphical environment have the same session id as one of the startup programs. This allows the OS to perform the same kill -HUP -$$ operation on all the programs: such as your browser, music player, libreoffice, IM client, etc. These are the processes that are not session leaders.

share|improve this answer
    
Please don't mind but I might need a little more clarification - - session leader is one, what are the others called, and what are they like (behavior, what do they do different from Session Leader)? –  its_me Aug 6 '11 at 3:26
    
They are called member of the session, I believe. –  Arcege Aug 6 '11 at 18:48
    
I like your explanation but I'm still missing one point: IIUC, at any time every process I started is actually child of the shell I logged in with (unless I disowned it, of course). Why wouldn't OS just walk the process tree and kill all siblings of this process and their siblings? (Actually that's what I always thought it does...until today :D) So what is the rationale behind using sessions instead? –  Alois Mahdal May 13 '12 at 21:23
    
There needs to be a away of determining when a process is no longer part of the original session (login shell or daemon, for example). One thought might be to automatically change the PPID (parent pid) to 1, but that does break the process tree. A new session id creates a group that could be sent a signal together. An example of this is the GUI, fire off firefox as a separate session. Then, when the [X] button is pressed, send a signal the firefox's session and its children, but the window manager is not affected - couldn't do this with straight PPID-PID relationships. –  Arcege May 14 '12 at 0:18
    
When the GUI dies, then the entire process tree, not the session group, could get the signal. Two different desired behaviors: killing one 'app' (kill firefox and its plugins), versus killing all child processes (exiting a gui). Similar workings with emacs and chrome, I expect. –  Arcege May 14 '12 at 0:21

I thought I knew the answer to this, but I wrote a C program to figure this out.

#include <stdio.h>
#include <unistd.h>

int
main(int ac, char **av)
{
        pid_t sid, mypid, pgid, gid;

        mypid = getpid();
        sid = getsid(0);
        pgid = getpgid(0);
        gid = getpgrp();

        printf("PID %d\n", mypid);
        printf("process group ID of session leader: %d\n", sid);
        printf("process group ID: %d\n", pgid);
        printf("process group ID: %d\n", gid);

        if (!fork())
        {
                mypid = getpid();
                sid = getsid(0);
                pgid = getpgid(0);
                gid = getpgrp();

                printf("child PID %d\n", mypid);
                printf("process group ID of session leader: %d\n", sid);
                printf("process group ID: %d\n", pgid);
                printf("process group ID: %d\n", gid);

                _exit(0);
        }

        return 0;
}

I compiled it with cc -g -o sid sid.c I ran it a few different ways, to see what happens:

./sid
nohup ./sid > sid.out
setsid ./sid

I was kind of surprised by what Linux (2.6.39) gave back. I also found the section 7 man page, "credentials".

My advice is to do man 7 credentials (or the equivalent if not on Linux), and read the section about process group and session to see if you can puzzle it out.

share|improve this answer
    
Being a linux newbie, I couldn't make out what you said. Looks like you are puzzled too? But you are probably knowledgeable enough to understand what Arcege's answer meant. If you do, can you please explain the same in more clarity? –  its_me Aug 6 '11 at 3:30
    
Interesting... thanks... So, the session id (SID) is the terminal's PID for ./sid and nohup ./sid, and when you run setsid ./sid, the session id (SID) is brand new and is the same as the process PID... I'm not sure why nohup prevented the fork (or seems to), but I think I've got the general idea... –  Peter.O Aug 6 '11 at 10:02

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.