POSIX Process Group !

If you want to kill a process by its pid with all its sub process and dont want the child process to continue under init process ? Then process group is the one you may want to look at.

p1->p2->p3

By using p1, if you want to kill entire p1,p2 and p3 then we can look into process group. Remember that linux kill command has a option to send signals to entire process group like this :

kill -s sig_num -pid

Also, if you want to start a process through a cgi script and detach it completely from httpd process this would be helpful.

A small program to showcase the use of POSIX setsid.

use POSIX qw(setsid);

chdir '/'                 or die "Can't chdir to /: $!";
umask 0;
open STDIN, '/dev/null'   or die "Can't read /dev/null: $!";
#open STDOUT, '>/dev/null' or die "Can't write to /dev/null: $!";
open STDERR, '>/dev/null' or die "Can't write to /dev/null: $!";
defined(my $pid = fork)   or die "Can't fork: $!";
exit if $pid;
setsid                    or die "Can't start a new session: $!";

while(1) {
sleep(5);
print "Hello...\n";
}

Further details on the process groups ...

Process Groups and Tty Management

One of the areas least-understood by most UNIX programmers is process-group management, a topic that is inseparable from signal-handling.

To understand why process-groups exist, think back to the world before windowing systems.

Your average developer wants to run several programs simultaneously -- usually at least an editor and a compilation, although often a debugger as well. Obviously you cannot have two processes reading from the same tty at the same time -- they'll each get some of the characters you type, a useless situation. Likewise output should be managed so that your editor's output doesn't get the output of a background compile intermixed, destroying the screen.

This has been a problem with many operating systems. One solution, used by Tenex and TOPS-20, was to use process stacks. You could interrupt a process to run another process, and when the new process was finished the old would restart.

While this was useful it didn't allow you to switch back and forth between processes (like a debugger and editor) without exiting one of them. Clearly there must be a better way.

The Berkeley Approach

The Berkeley UNIX folks came up with a different idea, called process groups. Whenever the shell starts a new command each process in the command (there can be more than one, eg "ls | more") is placed in its own process group, which is identified by a number. The tty has a concept of "foreground process group", the group of processes which is allowed to do input and output to the tty. The shell sets the foreground process group when starting a new set of processes; by convention the new process group number is the same as the process ID of one of the members of the group. A set of processes has a tty device to which it belongs, called its "controlling tty". This tty device is what is returned when /dev/tty is opened.

Because you want to be able to interrupt the foreground processes, the tty watches for particular keypresses (^Z is the most common one) and sends an interrupt signal to the foreground process group when it sees one. All processes in the process group see the signal, and all stop -- returning control to the shell.

At this point the shell can place any of the active process groups back in the foreground and restart the processes, or start a new process group.

To handle the case where a background process tries to read or write from the tty, the tty driver will send a SIGTTIN or SIGTTOU signal to any background process which attempts to perform such an operation. Under normal circumstances, therefore, only the foreground process(es) can use the tty.

The set of commands to handle process groups is small and straightforward. Under BSD, the commands are:

int setpgrp(int process_id, int group_number);

Move a process into a process group. If you are creating a new process group the group_number should be the same as process_id. If process_id is zero, the current process is moved.

int getpgrp(int process_id);

Find the process group of the indicated process. If process_id is zero, the current process is inspected.

int killpgrp(int signal_number, int group_number);

Send a signal to all members of the indicated process group.

int ioctl(int tty, TIOCSETPGRP, int foreground_group);

Change the foreground process group of a tty.

int ioctl(int tty, TIOCGETPGRP, int *foreground_group);

Find the foreground process group of a tty.

int ioctl(int tty, TIOCNOTTY, 0);

Disassociate this process from its controlling tty. The next tty device that is opened will become the new controlling tty.

The POSIX Approach

The BSD process-group API is rarely used today, although most of the concepts survive. The POSIX specification has provided new interfaces for handling process groups, and even overloaded some existing ones. It also limits several of the calls in ways which BSD did not.

The POSIX process-group API is:

int setpgid(int process_id, int process_group);

Move a process into a new process group. Process_id is the process to move, process_group is the new process group.

int getpgid(int process_id);

Find the process group of a process. Process_id is the process to inspect.

int getpgrp(void);

Find the process group of the current process. This is identical to getpgrp(getpid()).

int tcsetpgrp(int tty, int foreground_group);

Change the foreground process group of a tty. Tty is the file descriptor of the tty to change, foreground_group is the new foreground process group.

int tcgetpgrp(int tty, int *foreground_group);

Find the foreground process group of a tty. Tty is the file descriptor of the tty to inspect, foreground_group is returned filled with the foreground process group of the tty.

int kill(int -process_group, int signal_number);

Send a signal to a process group. Note that process_group must be passed as a negative value, otherwise the signal goes to the indicated process.

Differences between POSIX and BSD Process Group Management

The setpgrp() function is called setpgid() under POSIX and is essentially identical. You must be careful under POSIX not to use the setpgrp() function -- usually it exists, but performs the operation of setsid().

The getpgrp() function was renamed getpgid(), and getpgid() can only inspect the current process' process group.

The killpgrp() function doesn't exist at all. Instead, a negative value passed to the kill() function is taken to mean the process group. Thus you'd perform killpgrp(process_group) by calling kill(-process_group).

The ioctl() commands for querying and changing the foreground process group are replaced with first-class functions:

• int tcsetpgrp(int tty, int process_group);
• int tcgetpgrp(int tty, int *process_group);

While the original BSD ioctl() functions would allow any tty to take on any process group (or even nonexistant process groups) as its foreground tty, POSIX allows only process groups which have the tty as their controlling tty. This limitation disallows some ambiguous (and potentially security-undermining) cases present in BSD.

The TIOCNOTTY ioctl used in BSD is replaced with the setsid() function, which is essentially identical to:

if (getpgrp() != getpid()) { ioctl(tty, TIOCNOTTY, 0); setpgrp(getpid(), getpid()); }

It releases the current tty and puts the calling process into its own process group. Notice that nothing is done if the calling process is already in its own process group -- this is another new limitation, and eliminates some ambiguous cases that existed in BSD (along with some of BSD's flexibility).

Reference : http://www.cs.ucsb.edu/~almeroth/classes/W99.276/assignment1/signals.html

Vim - Cheatsheet

A cheat sheet of some useful and most often used Vim commands. This Vim cheat sheet isn't trying to include all the Vim commands in the known universe, but should list the most essential ones.

Author: Nana Långstedt <>
tuXfile created: 18 January 2003
Last modified: 22 September 2005

< The list of Vim commands >

Working with files
Vim command	Action
:e filename	Open a new file. You can use the Tab key for automatic file name completion, just like at the shell command prompt.
:w filename	Save changes to a file. If you don't specify a file name, Vim saves as the file name you were editing. For saving the file under a different name, specify the file name.
:q	Quit Vim. If you have unsaved changes, Vim refuses to exit.
:q!	Exit Vim without saving changes.
:wq	Write the file and exit.
:x	Almost the same as :wq, write the file and exit if you've made changes to the file. If you haven't made any changes to the file, Vim exits without writing the file.
Moving in the file
These Vim commands and keys work both in command mode and visual mode.
Vim command	Action
j or Up Arrow	Move the cursor up one line.
k or Down Arrow	Down one line.
l or Right Arrow	Right one character.
h or Left Arrow	Left one character.
e	To the end of a word.
E	To the end of a whitespace-delimited word.
b	To the beginning of a word.
B	To the beginning of a whitespace-delimited word.
0	To the beginning of a line.
^	To the first non-whitespace character of a line.
$	To the end of a line.
H	To the first line of the screen.
M	To the middle line of the screen.
L	To the the last line of the screen.
:n	Jump to line number n. For example, to jump to line 42, you'd type :42
Inserting and overwriting text
Vim command	Action
i	Insert before cursor.
I	Insert to the start of the current line.
a	Append after cursor.
A	Append to the end of the current line.
o	Open a new line below and insert.
O	Open a new line above and insert.
C	Change the rest of the current line.
r	Overwrite one character. After overwriting the single character, go back to command mode.
R	Enter insert mode but replace characters rather than inserting.
The ESC key	Exit insert/overwrite mode and go back to command mode.
Deleting text
Vim command	Action
x	Delete characters under the cursor.
X	Delete characters before the cursor.
dd or :d	Delete the current line.
Entering visual mode
Vim command	Action
v	Start highlighting characters. Use the normal movement keys and commands to select text for highlighting.
V	Start highlighting lines.
The ESC key	Exit visual mode and return to command mode.
Editing blocks of text
The Vim commands marked with (V) work in visual mode, when you've selected some text. The other commands work in the command mode, when you haven't selected any text.
Vim command	Action
~	Change the case of characters. This works both in visual and command mode. In visual mode, change the case of highlighted characters. In command mode, change the case of the character uder cursor.
> (V)	Shift right.
< (V)	Shift left.
c (V)	Change the highlighted text.
y (V)	Yank the highlighted text. In Winblows terms, "copy the selected text to clipboard."
d (V)	Delete the highlighted text. In Winblows terms, "cut the selected text to clipboard."
yy or :y or Y	Yank the current line. You don't need to highlight it first.
dd or :d	Delete the current line. Again, you don't need to highlight it first.
p	In Winblows terms, "paste" the contents of the "clipboard". In Vim terms, you "put" the text you yanked or deleted. Put characters after the cursor. Put lines below the current line.
P	Put characters before the cursor. Put lines above the current line.
Undo and redo
Vim command	Action
u	Undo the last action.
U	Undo all the latest changes that were made to the current line.
Ctrl + r	Redo.
Search
Vim command	Action
/pattern	Search the file for pattern.
n	Scan for next search match in the same direction.
N	Scan for next search match but opposite direction.
Replace
Vim command	Action
:rs/foo/bar/a	Substitute foo with bar. r determines the range and a determines the arguments.
The range (r) can be
nothing	Work on current line only.
number	Work on the line whose number you give.
%	The whole file.
Arguments (a) can be
g	Replace all occurrences in the line. Without this, Vim replaces only the first occurrences in each line.
i	Ignore case for the search pattern.
I	Don't ignore case.
c	Confirm each substitution. You can type y to substitute this match, n to skip this match, a to substitute this and all the remaining matches ("Yes to all"), and q to quit substitution.
Examples
:452s/foo/bar/	Replace the first occurrence of the word foo with bar on line number 452.
:s/foo/bar/g	Replace every occurrence of the word foo with bar on current line.
:%s/foo/bar/g	Replace every occurrence of the word foo with bar in the whole file.
:%s/foo/bar/gi	The same as above, but ignore the case of the pattern you want to substitute. This replaces foo, FOO, Foo, and so on.
:%s/foo/bar/gc	Confirm every substitution.
:%s/foo/bar/c	For each line on the file, replace the first occurrence of foo with bar and confirm every substitution.

Play Windows Games on Linux - Try Cedega Today !

So, you are 1 out of many people who use windows just for gaming ??? If so, you can try this cedega tool and check whether your favourite game works on linux ! There are a few options when it comes to playing Windows games on Linux. Cedega is a great tool to allow you to play these games under Linux.

You can check whether your favourite game is supported by cedega here. (http://www.cedega.com/gamesdb/)

Remember that latest versions of cedega is not free. You may need to subscribe it here http://www.cedega.com/subscription/subscribe.html

But, older stable version can be downloaded from their cvs and compiled :)

Compilation Instructions : http://www.linux-gamers.net/modules/wiwimod/index.php?page=HOWTO+Cedega+CVS

Help Script : http://winecvs.linux-gamers.net/index.php/Main_Page

If you are scared about compiling by yourself, dont worry ! Your favourite linux distribution (Ubuntu, Suse, Fedora ...) might have already packaged it for you. Just check in their repositories :)

Linux Signals for the Application Programmer

Introduction about the usage of signals in Linux ...

A good understanding of signals is important for an application programmer working in the Linux environment. Knowledge of the signaling mechanism and familiarity with signal-related functions help one write programs more efficiently.

An application program executes sequentially if every instruction runs properly. In case of an error or any anomaly during the execution of a program, the kernel can use signals to notify the process. Signals also have been used to communicate and synchronize processes and to simplify interprocess communications (IPCs). Although we now have advanced synchronization tools and many IPC mechanisms, signals play a vital role in Linux for handling exceptions and interrupts. Signals have been used for approximately 30 years without any major modifications.

The first 31 signals are standard signals, some of which date back to 1970s UNIX from Bell Labs. The POSIX (Portable Operating Systems and Interface for UNIX) standard introduced a new class of signals designated as real-time signals, with numbers ranging from 32 to 63.

A signal is generated when an event occurs, and then the kernel passes the event to a receiving process. Sometimes a process can send a signal to other processes. Besides process-to-process signaling, there are many situations when the kernel originates a signal, such as when file size exceeds limits, when an I/O device is ready, when encountering an illegal instruction or when the user sends a terminal interrupt like Ctrl-C or Ctrl-Z.

Every signal has a name starting with SIG and is defined as a positive unique integer number. In a shell prompt, the kill -l command will display all signals with signal number and corresponding signal name. Signal numbers are defined in the /usr/include/bits/signum.h file, and the source file is /usr/src/linux/kernel/signal.c.

A process will receive a signal when it is running in user mode. If the receiving process is running in kernel mode, the execution of the signal will start only after the process returns to user mode.

Signals sent to a non-running process must be saved by the kernel until the process resumes execution. Sleeping processes can be interruptible or uninterruptible. If a process receives a signal when it is in an interruptible sleep state, for example, waiting for terminal I/O, the kernel will awaken the process to handle the signal. If a process receives a signal when it is in uninterruptible sleep, such as waiting for disk I/O, the kernel defers the signal until the event completes.

When a process receives a signal, one of three things could happen. First, the process could ignore the signal. Second, it could catch the signal and execute a special function called a signal handler. Third, it could execute the default action for that signal; for example, the default action for signal 15, SIGTERM, is to terminate the process. Some signals cannot be ignored, and others do not have default actions, so they are ignored by default. See the signal(7) man page for a reference list of signal names, numbers, default actions and whether they can be caught.

When a process executes a signal handler, if some other signal arrives the new signal is blocked until the handler returns. This article explains the fundamentals of the signaling mechanism and elaborates on signal-related functions with syntax and working procedures.

Signals inside the Kernel

Where is the information about a signal stored in the process? The kernel has a fixed-size array of proc structures called the process table. The u or user area of the proc structure maintains control information about a process. The major fields in the u area include signal handlers and related information. The signal handler is an array with each element for each type of signal being defined in the system, indicating the action of the process on the receipt of the signal. The proc structure maintains signal-handling information, such as masks of signals that are ignored, blocked, posted and handled.

Once a signal is generated, the kernel sets a bit in the signal field of the process table entry. If the signal is being ignored, the kernel returns without taking any action. Because the signal field is one bit per signal, multiple occurrences of the same signal are not maintained.

When the signal is delivered, the receiving process should act depending on the signal. The action may be terminating the process, terminating the process after creating a core dump, ignoring the signal, executing the user-defined signal handler (if the signal is caught by the process) or resuming the process if it is temporarily suspended.

The core dump is a file called core, which has an image of the terminated process. It contains the process' variables and stack details at the time of failure. From a core file, the programmer can investigate the reason for termination using a debugger. The word core appears here for a historical reason: main memory used to be made from doughnut-shaped magnets called inductor cores.

Catching a signal means instructing the kernel that if a given signal has occurred, the program's own signal handler should be executed, instead of the default. Two exceptions are SIGKILL and SIGSTOP, which cannot be caught or ignored.

sigset_t is a basic data structure used to store the signals. The structure sent to a process is a sigset_t array of bits, one for each signal type:

typedef struct {
                  unsigned long sig[2];
               }  sigset_t;

Because each unsigned long number consists of 32 bits, the maximum number of signals that may be declared in Linux is 64 (according to POSIX compliance). No signal has the number 0, so the other 31 bits in the first element of sigset_t are the standard first 31 signals, and the bits in the second element are the real-time signal numbers 32-64. The size of sigset_t is 128 bytes.

Reference : http://m.linuxjournal.com/article/6483

Managing Tasks on x86 Processors !

Just came across an article about tasks in x86 ...

Intel's x86 microprocessors can automatically manage tasks just like a simple operating system. There are many tricks and pitfalls, however, but with the right approach the programmer can get great performance at zero cost.

Just about every embedded system does some sort of task switching or task management. You don't always have to use a full-size operating system or RTOS to do task management; sometimes a little kernel executive is enough or even a quick time-slice interrupt. In the extreme case, you don't need any software at all: the processor can manage tasks for you. In this article, we'll drill into the x86 task-management features.

Hardware task-management started with the '386 and continues to this day on chips like the old '486 and Pentium as well as the newer Athlon, Opteron, and Pentium 4 processors. It's a terrific feature for embedded systems programmers because it makes task management fairly simple and foolproof. Whether you're managing just two tasks or dozens, you can probably let the chip do it all for you—for free.

Reference : http://www.embedded.com/columns/technicalinsights/55301875?_requestid=14392

Anatomy of a Program in Memory

Just found it interesting about linux memory management ...

Memory management is the heart of operating systems; it is crucial for both programming and system administration. In the next few posts I’ll cover memory with an eye towards practical aspects, but without shying away from internals. While the concepts are generic, examples are mostly from Linux and Windows on 32-bit x86. This first post describes how programs are laid out in memory.

Each process in a multi-tasking OS runs in its own memory sandbox. This sandbox is the virtual address space, which in 32-bit mode is always a 4GB block of memory addresses. These virtual addresses are mapped to physical memory by page tables, which are maintained by the operating system kernel and consulted by the processor. Each process has its own set of page tables, but there is a catch. Once virtual addresses are enabled, they apply to all software running in the machine, including the kernel itself. Thus a portion of the virtual address space must be reserved to the kernel:

Please continue reading from the reference site ...

Reference : http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory

Hello, world! - Assembly in Linux

One program which I like most. This would be my first program in any language which Im learning. Because, this helps me to setup that programming environment and also which gives me a lot of confidence :)

 ## hello-world.s

 ## by Robin Miyagi
 ## http://www.geocities.com/SiliconValley/Ridge/2544/

 ## Compile Instructions:
 ## -------------------------------------------------------------
 ## as -o hello-world.o hello-world.s
 ## ld -o hello-world -O0 hello-world.o

 ## This  file is  a basic  demonstration of  the  GNU assembler,
 ## `as'.
 
 ## This program  displays a friendly string on  the screen using
 ## the write () system call
########################################################################
 .section .data
hello: 
 .ascii  "Hello, world!\n"
hello_len:
 .long  . - hello
########################################################################
 .section .text
 .globl _start
 
_start:
 ## display string using write () system call
 xorl %ebx, %ebx  # %ebx = 0
 movl $4, %eax  # write () system call
 xorl %ebx, %ebx  # %ebx = 0
 incl %ebx  # %ebx = 1, fd = stdout
 leal hello, %ecx # %ecx ---> hello
 movl hello_len, %edx # %edx = count
 int $0x80  # execute write () system call
 
 ## terminate program via _exit () system call
 xorl %eax, %eax  # %eax = 0
 incl %eax  # %eax = 1 system call _exit ()
 xorl %ebx, %ebx  # %ebx = 0 normal program return code
 int $0x80  # execute system call _exit ()

Of course, credits goes to the author.