Home / All posts

Mastering The Linux Shell : Standard In, Out, and Error

Posted by Unknown Minggu, 31 Maret 2013 0 komentar
http://marcelgagne.com/content/mastering-linux-shell-standard-out-and-error


Welcome to part four in my Mastering The Linux Shell series where we will wander wistfully into a land where three terribly under-appreciated but vitally important files live. You will remember that everything is a file, including directories which some people call folders. What you may not know is that your keyboard is a file, as is the screen on which you read these words. And if all hell breaks loose, all that goes into a file too. Those special files, and variations on those files, are always in use, unlike those other, less hard-working files that seem to get all the credit. They are called STDIN, STDOUT, and STDERR.
Standard in (STDIN) is where the system expects to find its input. This is usually the keyboard, although it can be a program or shell script. When you change that default, you call it redirecting from STDIN.
Standard out (STDOUT) is where the system expects to direct its output, usually the terminal screen. Again, redirection of STDOUT is at the discretion of whatever command or script is executing at the time. The chain of events from STDIN to STDOUT looks something like this:
standard in  -> Linux command  ->  standard out
STDIN is often referred to as fd0, or file descriptor 0, while STDOUT is usually thought of as fd1. There is also standard error (STDERR), where the system reports any errors in program execution. By default, this is also the terminal. To redirect STDOUT, use the greater-than sign (>). As you might have guessed, to redirect from STDIN, you use the less-than sign (<). But what exactly does that mean? Let’s try an experiment. Randomly search your brain and pick a handful of names. Got them? Good. Now type the cat command and redirect its STDOUT to a file called random_names.
cat > random_names
Your cursor will just sit there and wait for you to do something, so type those names, pressing Enter after each one. What’s happening here is that cat is taking its input from STDIN and writing it out to your new file. You can also write the command like this:
cat - 1> random_names
The hyphen literally means standard in to the command. The 1 stands for file descriptor 1. This is good information, and you will use it later. Finished with your random names list? When you are done, press to finish. , by the way, stands for EOF, or end of file.
Marie Curie
Albert Einstein
Mark Twain
Wolfgang Amadeus Mozart
Stephen Hawking
Hedy Lamarr
^D
If you cat this file, the names will be written to STDOUT, in this case, your terminal window. You can also give cat several files at the same time. For instance, you could do something like this:
cat file1 file2 file3
Each file would be listed one right after the other. That output could then be redirected into another file. You could also have it print out the same file over and over (cat random_names random_names random_names). cat isn’t fussy about these things and will deal with binary files (programs) just as quickly. Beware of using cat to print out the contents of a program to your terminal screen. At worst, your terminal session will lock up or reward you with a lot of beeping and weird characters.
If you get caught in such a situation and all the characters on your screen appear as junk, try typing echo and then pressing and . If you can still type, you can also try typing stty sane and then pressing . Some systems also provide a command called reset which will return your terminal session to some kind of sane look.
Redirecting STDIN works pretty much the same way, except that you use the less-than sign instead. Using the sort command, let’s take that file of random names and work with it. Many commands that work with files can take their input directly from that file. Unless told otherwise, cat and sort will think that the word following the command is a filename. That’s why you did the STDIN redirection thing. Yes, that’s right: STDIN is just another file. Sort of.
sort random_names
The result, of course, is that you get all your names printed out in alphabetical order. You could have also specified that sort take its input from a redirected STDIN. It looks a bit strange, but this is perfectly valid.
$ sort < random_names
Albert Einstein
Hedy Lamarr
Marie Curie
Mark Twain
Stephen Hawking
Wolfgang Amadeus Mozart
One more variation involves defining your STDIN (as you did previously) and specifying a different STDOUT all on the same line. In the following example, I am redirecting from my file and redirecting that output to a new file:
sort < random_names > sorted_names

Pipes and Piping

Sometimes the thing that makes the most sense is to feed the output from one command directly into another command without having to resort to files in between at every step of the way. This is called piping. The symbolism is not that subtle: Imagine pieces of pipe connecting one command with another. Not until you run out of pipe does the command’s output emerge. The pipe symbol is the broken vertical bar on your keyboard usually located just below or (depending on the keyboard) just above the Enter key and sharing space with the backslash key. Here’s how it works:
cat random_names | sort | wc –w > num_names
In the preceding example, the output from the cat command is piped into sort, whose output is then piped into the wc command (that’s "word count"). The -w flag tells wc to count the number of words in random_names. So far, so good.
That cat at the beginning is actually redundant, but I wanted to stack up a few commands for you to give you an idea of the power of piping. Ordinarily, I would write that command as follows:
sort random_names | wc –w > num_names
The cat is extraneous because sort incorporates its function. Using pipes is a great timesaver because you don’t always need to have output at every step of the way.

tee: A Very Special Pipe

Suppose that you want to send the output of a command to another command, but you also want to see the results at some point. Using the previous word count example, if you want a sorted list of names, but you also want the word count, you might have to use two different commands: one to generate the sorted list and another to count the number of words. Wouldn’t it be nice if you could direct part of the output one way and have the rest continue in another direction? For this, use the tee command.
sort random_names | tee sorted_list | wc –w > num_names
The output from sort is now sitting in a file called sorted_list, while the rest of the output continues on to wc for a word count.

STDERR

What about STDERR? Some commands (many, in fact) treat the error output differently than the STDOUT. If you are running the command at your terminal and that’s all you want, there is no problem. Sometimes, though, the output is quite wordy and you need to capture it and look at it later. Unfortunately, using the STDOUT redirect (the greater-than sign) is only going to be so useful. Error messages that might be generated (such as warning messages from a compilation) will go to the terminal as before. One way to deal with this is to start by redirecting STDERR to STDOUT, and then redirect that to a file. Here’s the line I use for this:
command_name 2>&1 > logfile.out
Remember that file descriptor 2 is STDERR and that file descriptor 1 is STDOUT. That’s what that 2>&1 construct is all about. You are redirecting fd2 to fd1 and then redirecting that output to the file of your choice. Using that program compilation example, you might wind up with something like this:
make –f Makefile.linux 2>&1 > compilation.output
The final greater-than sign in the preceding example could be eliminated completely. When using the 2>&1 construct, it is assumed that what follows is a filename.

The Road to Nowhere

If the command happens to be verbose by nature and doesn’t have a quiet switch (that's usually a -q option), you can redirect that STDOUT and STDERR noise to what longtime  Linux users like to call the bit bucket, a special file called /dev/null, literally, a road to nowhere. Anything fed to the bit bucket takes up no space and is never seen or heard from again. When I was in school, way back in the before time, we would tell people to shut up by saying, "Dev null it, will you?" As you can see, we were easily amused.
To redirect output to the bit bucket, use the STDOUT redirection.
command –option > /dev/null
If, for some strange reason, you want to sort the output of the random_names files and you do not want to see the output, you can redirect the whole thing to /dev/null in this way:
sort random_names > /dev/null
Using the program compilation example where you had separate STDOUT and STDERR streams, you can combine the output to the bit bucket.
make –F makefile.linux 2>&1 /dev/null
That’s actually a crazy example because you do want to see what goes on, but redirecting both STDOUT and STDERR to /dev/null is quite common when dealing with automated processes running in the background.
And once again, it's time to wrap it up. Look for part 5 of this series coming your way on Monday. And that is where I will leave this discussion for today. Leave any comments you may have here on Google Plus or over here on Facebook. Join me this coming Thursday for part four in this series. Remember that you can also follow the action on CookingWithLinux.com where it's all Linux, all the time. Except for the occasional wine review.

Baca Selengkapnya ....
Categories:

4 gui applications for installing Linux from USB key

Posted by Unknown Kamis, 28 Maret 2013 0 komentar
http://www.linuxbsdos.com/2013/03/26/linux-live-usb-best-tool-to-install-linux-on-usb


The traditional and most common method of installing Linux is by burning the installation ISO image to a CD or DVD. But with many laptops, notebooks, ultra notebooks, subnotebooks shipping without an optical drive, installation via USB flash stick has become the most common method for installing Linux on these types of computers. That’s were a Linux USB installer come into play.
In our neck of the woods, where virtually all computers running a Linux or UNIX-like operating system did not ship with them pre-installed, users are very familiar with the tools to burn or transfer their favorite distribution to removable media. The same cannot be said for those on the other side.
With this article, four of the best graphical applications that Windows users may use to transfer most actively-developed Linux distributions to a USB key, and, therefore, use it to install the Linux distribution to a computer that does not have an optical drive are presented.
Note that these applications do not just make it easy to install a Linux distribution from a USB key, but also allow you to run supported distributions in Live mode, that is, run it from the USB stick without installing it to the computer’s hard disk drive (HDD). In that (Live) mode, they also allow you to have persistent storage on the USB stick, such that any data you store on the USB key is not lost when the computer is rebooted.
They also have other features in common. For example, you can install an installation image of supported distributions stored locally, or they can automatically download a supported distribution from the nearest download mirror. Because they don’t have support for the very latest of many distributions, I find it more convenient to manually download my distribution of choice and point the application to the download directory.
In no particular order, the applications are:
1. LinuxLive USB Creator: This has a beautiful and flowery graphical interface. It is a Windows-only application and has supported for many popular distributions. I find it kinda fun to use. LinuxLive USB Creator or LiLi, may be downloaded from here.
LinuxLive USB Linux USB installer
A distribution can be downloaded from the nearest mirror.
linux usb installer
2. Unetbootin: This runs on Windows and Linux. Its interface is not as fancy as the LinuxLive USB Creator’s, but it gets the job done.
Unetbootin Linux USB Installer
Its list of supported distributions tend to be one or two revisions removed from the current stable release.
Unetbootin USB installer
For example, the last “stable” release of BackTrack is BackTrack 5 R3, which has since been replaced by Kali Linux. Unetbootin is available for download here.
Unetbootin Live USB Installer
3. Universal USB Installer: This runs only on Windows. Universal USB Installer (UUI). Like Unetbootin and LinuxLive USB Creator, UUI does not support all distributions, but it does give you the option of attempting to install an unsupported distribution on a USB Flash drive. I tried it with Mageia 2, and it did not work. You may download UUI from Universal USB Installer.
UUI Live USB Installer
4. Your Universal Multiboot Installer: This is from the same author as UUI, and it, too, runs only on Windows. The only feature that sets Your Universal Multiboot Installer (YUMI) apart from the others is the claim that it can install more than one distribution on the same USB key.
YUMI Linux Live USB Installer
I haven’t tried it yet, but I’ll attempt it before the end of the day and let you know what happened. YUMI is available for download here.
YUMI Linux Live USB Installer
Being able to install a Linux distribution from a USB key or USB flash drive is neat, but when it comes to running it in Live mode and storing persistent data on it, I’d rather install the distribution on an SSD or a small, external HDD. Then I don’t have to worry about how much persistent storage space I can allocate to it.

Baca Selengkapnya ....
Categories:

Linux processes explained

Posted by Unknown 0 komentar
http://mylinuxbook.com/linux-processes-part1


Generally, on any operating system, we say we have so many programs running. These running programs introduce the concept of processes. Let’s Define as to what is a process – A process is a program in execution.
Robert Love expresses his definition of a process in one of his books as :
The Process is one of the fundamental abstractions in Unix Operating Systems, the other fundamental abstraction being files
Linux is a multi-user and multi-tasking operating system(seemingly, discussed later in the article). A Linux process is a program in execution on a Linux system. Therefore, whenever a program is executed, a new process is created. A process also consumes resources like the file system, memory or other CPU resources. This gives rise to the need of process management in Linux.

Identifier for Linux Processes

In Linux, every process has a unique process Identifier(ID) associated to it. A process ID( i.e. PID) is a number which is uniquely assigned as soon as the process is created. The PID’s are allocated sequentially as the processes are being created. However, it generally starts from 2, as PID=1 is reserved for ‘init process. As we always expect, there is a maximum limit to the PID value. In a system, the way one can get to know the maximum limit to PID is
$ cat /proc/sys/kernel/pid_max
For me, I got the following value
32768
Hence, whenever the sequentially allocated PID reaches the maximum value, it wraps to the lower limit(generally 300) and the next PID’s allocated are the available ones starting from the lower limit.
The PID of the process, as the name suggests is its identifier. Hence, most of the operations being done on a process needs the PID to be mentioned.
We shall see in the following sections, how do we see display all the processes with their PID’s and various operations that can be performed on a process.

Listing Processes

At any moment, the Linux user can view the list of all the processes which have been created and not terminated. There is a reason I don’t say all the processes which are running, as once a process has been started, it can be in any state, not necessarily running. More about process states in further sections.
The Linux command used to view list of processes is ‘ps’ which means ‘process status’ (Some authors also interpret it as ‘process snapshot’).
To see what all this Linux command has to offer in detail, the best source is the man-page.
Let us try out running the command
$ ps

 PID TTY          TIME CMD

1779 pts/0    00:00:00 bash

2176 pts/0    00:00:00 ps
We just see two processes! Although we are sure there are other processes being running as well. Well, the ‘ps’ command without any options just lists the processes which are created by the current terminal. The first one is the ‘bash’ which is the running linux shell by the terminal and other is the process created by ‘ps’ command itself.
Getting to know from the ‘ps’ output, let’s walk through it column by column.
  • PID – The process Identifier which is ‘1779’ for ‘bash’ and ‘2176’ for ‘ps’.
  • TTY – stands for terminal-type and is the name of the console/terminal, the process is associated to.
Note: To determine the name of your terminal, use command ‘tty’.
  • TIME – The CPU time since the process has started. It is confusing that why the CPU time for ‘bash’ process is ‘00:00:00’? This is because, CPU time is the time for which the process is being executed by the processor. However, when bash runs commands,lets say ‘ls command’ , a child process ‘ls’ is spawned and whatever execution and cpu utilization takes place, goes under the ‘ls’ process and not ‘bash’ Bash process is just the parent process.
  • CMD – Command run to create the process.
There are many more options offered by the Linux command ‘ps’ to explore the various processes being launched in a system. Kindly go back to the referred man-page of ‘ps’ to get familiar with each and every available option. Here we shall be playing around with a few.

List All processes

$ps -e
If we look at the ‘ps’ man page, ‘-e’ option means “Select all processes”, which implies now our list of displayed processes is not limited to the ones by the current terminal. Instead, we’ll be able to see all the currently running processes. Note, this option is identical to ‘-A’.
Running the above command, we see a huge list of processes. Hence, to read them through reasonably, we pipe the output to ‘more’
$ ps -e | more

PID TTY          TIME CMD

1 ?        00:00:00 init

2 ?        00:00:00 kthreadd

3 ?        00:00:01 ksoftirqd/0

5 ?        00:00:00 kworker/u:0

6 ?        00:00:00 migration/0

7 ?        00:00:00 watchdog/0

8 ?        00:00:00 cpuset

9 ?        00:00:00 khelper

10 ?        00:00:00 kdevtmpfs

11 ?        00:00:00 netns

12 ?        00:00:00 sync_supers

13 ?        00:00:00 bdi-default

14 ?        00:00:00 kintegrityd

15 ?        00:00:00 kblockd

16 ?        00:00:00 ata_sff

17 ?        00:00:00 khubd

18 ?        00:00:00 md

21 ?        00:00:00 khungtaskd

22 ?        00:00:01 kswapd0

23 ?        00:00:00 ksmd

24 ?        00:00:00 fsnotify_mark

25 ?        00:00:00 ecryptfs-kthrea

26 ?        00:00:00 crypto

34 ?        00:00:00 kthrotld

35 ?        00:00:00 kworker/u:2

36 ?        00:00:00 scsi_eh_0

38 ?        00:00:00 scsi_eh_1

39 ?        00:00:00 scsi_eh_2

61 ?        00:00:00 devfreq_wq

200 ?   00:00:01 jbd2/sda1-8

201 ?   00:00:00 ext4-dio-unwrit

219 ?   00:00:05 flush-8:0

368 ?   00:00:00 upstart-udev-br

375 ?   00:00:00 udevd

503 ?   00:00:00 kpsmoused

628 ?   00:00:00 upstart-socket-

656 ?   00:00:05 rsyslogd

680 ?   00:00:00 dbus-daemon

708 ?   00:00:00 modem-manager

--more--
Observe, that for each process we have just following four details in the output, similar to what has been discussed in the section above:
PID     TTY          TIME        CMD
In order to get more details about each process, we use option ‘-f’ alongwith. This option will add more details in the form of more columns.
$ps -ef
Again, to read through the huge list of output, page by page, we pipe the output to ‘more’ looks like:
$ps -ef | more

UID        PID  PPID  C STIME TTY          TIME CMD

root         1     0  0 Mar08 ?        00:00:00 /sbin/init

root         2     0  0 Mar08 ?        00:00:00 [kthreadd]

root         3     2  0 Mar08 ?        00:00:01 [ksoftirqd/0]

root         5     2  0 Mar08 ?        00:00:00 [kworker/u:0]

root         6     2  0 Mar08 ?        00:00:00 [migration/0]

root         7     2  0 Mar08 ?        00:00:00 [watchdog/0]

root         8     2  0 Mar08 ?        00:00:00 [cpuset]

root         9     2  0 Mar08 ?        00:00:00 [khelper]

root        10     2  0 Mar08 ?        00:00:00 [kdevtmpfs]

root        11     2  0 Mar08 ?        00:00:00 [netns]

root        12     2  0 Mar08 ?        00:00:00 [sync_supers]

root        13     2  0 Mar08 ?        00:00:00 [bdi-default]

root        14     2  0 Mar08 ?        00:00:00 [kintegrityd]

root        15     2  0 Mar08 ?        00:00:00 [kblockd]

root        16     2  0 Mar08 ?        00:00:00 [ata_sff]

root        17     2  0 Mar08 ?        00:00:00 [khubd]

root        18     2  0 Mar08 ?        00:00:00 [md]

root        21     2  0 Mar08 ?        00:00:00 [khungtaskd]

root        22     2  0 Mar08 ?        00:00:01 [kswapd0]

root        23     2  0 Mar08 ?        00:00:00 [ksmd]

root        24     2  0 Mar08 ?        00:00:00 [fsnotify_mark]

root        25     2  0 Mar08 ?        00:00:00 [ecryptfs-kthrea]

root        26     2  0 Mar08 ?        00:00:00 [crypto]

root        34     2  0 Mar08 ?        00:00:00 [kthrotld]

root        35     2  0 Mar08 ?        00:00:00 [kworker/u:2]

root        36     2  0 Mar08 ?        00:00:00 [scsi_eh_0]

root        38     2  0 Mar08 ?        00:00:00 [scsi_eh_1]

root        39     2  0 Mar08 ?        00:00:00 [scsi_eh_2]

root        61     2  0 Mar08 ?        00:00:00 [devfreq_wq]

root       200     2  0 Mar08 ?        00:00:01 [jbd2/sda1-8]

root       201     2  0 Mar08 ?        00:00:00 [ext4-dio-unwrit]

root       219     2  0 Mar08 ?        00:00:05 [flush-8:0]

root       368     1  0 Mar08 ?        00:00:00 upstart-udev-bridge --daemon

root       375     1  0 Mar08 ?        00:00:00 /sbin/udevd --daemon

root       503     2  0 Mar08 ?        00:00:00 [kpsmoused]

root       628     1  0 Mar08 ?        00:00:00 upstart-socket-bridge --daemon

syslog     656     1  0 Mar08 ?        00:00:05 rsyslogd -c5

102        680     1  0 Mar08 ?        00:00:00 dbus-daemon --system --fork --activation=upstart

root       708     1  0 Mar08 ?        00:00:00 /usr/sbin/modem-manager

--more--
Well, we have a new set of details of the running processes.
  • UID – The User ID,is the username of the user, which owns the process.
  • PID – Already discusses the Process ID.
  • PPID – It is the Parent Process ID. Mostly, all the processes, except the first one, have a parent process i.e. the process which has created our relevant process. Therefore, every process retains the PID of its parent process it calls as the parent process ID i.e. PPID, in its process descriptors. We shall learn about process descriptors in the next part of this article series. Meanwhile, one can understand process descriptors as some related parameters describing the process.
Therefore, we can conclude from here that, process can be represented as a tree (hierarchical) structure in Linux. To view the complete tree structure, linux provides a command – pstree.
It gives an interesting output, showcasing the first ‘init’ process and the other processes spawned out of it.
The process tree snapshot on my ubuntu system is:
$ pstree

init─┬─NetworkManager─┬─dhclient

    │                ├─dnsmasq

    │                └─2*[{NetworkManager}]

    ├─accounts-daemon───{accounts-daemon}

    ├─acpid

    ├─at-spi-bus-laun───2*[{at-spi-bus-laun}]

    ├─atd

    ├─avahi-daemon───avahi-daemon

    ├─bamfdaemon───2*[{bamfdaemon}]

    ├─bluetoothd

    ├─colord───2*[{colord}]

    ├─console-kit-dae─┬─63*[{console-kit-dae}]

    │                 └─{console-kit-dae}Dt\267

    ├─cron

    ├─cupsd───dbus

    ├─2*[dbus-daemon]

    ├─dbus-launch

    ├─dconf-service───2*[{dconf-service}]

    ├─deja-dup───2*[{deja-dup}]

    ├─firefox───22*[{firefox}]

    ├─gconfd-2

    ├─geoclue-master

    ├─6*[getty]

    ├─gnome-keyring-d─┬─4*[{gnome-keyring-d}]

    │                 └─{gnome-keyring-d}Dt\267

    ├─gnome-terminal─┬─bash───pstree

    │                ├─gnome-pty-helpe

    │                └─3*[{gnome-terminal}]

    ├─goa-daemon───{goa-daemon}

    ├─gvfs-afc-volume───{gvfs-afc-volume}Dt\267

    ├─gvfs-fuse-daemo───3*[{gvfs-fuse-daemo}]

    ├─gvfs-gdu-volume

    ├─gvfs-gphoto2-vo

    ├─gvfsd

    ├─gvfsd-burn

    ├─gvfsd-trash

    ├─hud-service───2*[{hud-service}]

    ├─indicator-appli───{indicator-appli}

    ├─indicator-datet─┬─{indicator-datet}

    │                 └─{indicator-datet}Dt\267

    ├─indicator-messa───{indicator-messa}Dt\267

    ├─indicator-print─┬─{indicator-print}

    │                 └─{indicator-print}Dt\267

    ├─indicator-sessi───2*[{indicator-sessi}]

    ├─indicator-sound─┬─{indicator-sound}

    │                 └─{indicator-sound}Dt\267

    ├─lightdm─┬─Xorg

    │         ├─lightdm─┬─gnome-session─┬─bluetooth-apple─┬─{bluetooth-apple}

    │         │         │               │                 └─{bluetooth-apple}Dt\267

    │         │         │               ├─deja-dup-monito───2*[{deja-dup-monito}]

    │         │         │               ├─gdu-notificatio───2*[{gdu-notificatio}]

    │         │         │               ├─gnome-fallback-───2*[{gnome-fallback-}]

    │         │         │               ├─gnome-screensav───2*[{gnome-screensav}]

    │         │         │               ├─gnome-settings-───2*[{gnome-settings-}]

    │         │         │               ├─metacity───3*[{metacity}]

    │         │         │               ├─nautilus───2*[{nautilus}]

    │         │         │               ├─nm-applet───2*[{nm-applet}]

    │         │         │               ├─polkit-gnome-au─┬─{polkit-gnome-au}

    │         │         │               │                 └─{polkit-gnome-au}Dt\267

    │         │         │               ├─ssh-agent

    │         │         │               ├─telepathy-indic───2*[{telepathy-indic}]

    │         │         │               ├─unity-2d-panel───2*[{unity-2d-panel}]

    │         │         │               ├─unity-2d-shell───5*[{unity-2d-shell}]

    │         │         │               ├─update-notifier─┬─{update-notifier}

    │         │         │               │                 └─{update-notifier}Dt\267

    │         │         │               └─3*[{gnome-session}]

    │         │         └─{lightdm}

    │         └─2*[{lightdm}]

    ├─mission-control─┬─{mission-control}

    │                 └─{mission-control}Dt\267

    ├─modem-manager

    ├─polkitd───{polkitd}

    ├─pulseaudio─┬─gconf-helper

    │            └─2*[{pulseaudio}]

    ├─rsyslogd───3*[{rsyslogd}]

    ├─rtkit-daemon───2*[{rtkit-daemon}]

    ├─system-service-

    ├─ubuntu-geoip-pr

    ├─udevd───2*[udevd]

    ├─udisks-daemon─┬─udisks-daemon

    │               └─{udisks-daemon}

    ├─unity-applicati─┬─{unity-applicati}

    │                 └─{unity-applicati}Dt\267

    ├─unity-files-dae─┬─{unity-files-dae}

    │                 └─{unity-files-dae}Dt\267

    ├─unity-lens-vide───{unity-lens-vide}

    ├─unity-music-dae───{unity-music-dae}Dt\267

    ├─unity-musicstor───{unity-musicstor}Dt\267

    ├─unity-panel-ser─┬─{unity-panel-ser}

    │                 └─{unity-panel-ser}Dt\267

    ├─unity-scope-vid─┬─{unity-scope-vid}

    │                 └─{unity-scope-vid}Dt\267

    ├─upowerd───2*[{upowerd}]

    ├─upstart-socket-

    ├─upstart-udev-br

    ├─whoopsie───{whoopsie}

    ├─zeitgeist-daemo───{zeitgeist-daemo}

    ├─zeitgeist-datah───{zeitgeist-datah}

    └─zeitgeist-fts─┬─cat

                    └─{zeitgeist-fts}
More information about the ‘pstree’ command can be fetched from its man page
  • C – The CPU usage and scheduling information. The value is incremented with every tick of the system clock, however degraded by the scheduler by dividing it by two in every second. Therefore, A higher value indicates CPU intensive process.
  • STIME – The start time of the process.
  • TTY – The terminal type associated with the process. If this value is ‘?’, then it means the process is not associated with any terminal. These are daemon process, which we shall be discussing in the next section.
  • TIME – The cumulative CPU time since the process is running.
  • CMD – The command which launched the process.
We shall see more usage of ‘ps’ command in further sections, as we come to know about other dimensions of the linux processes.

Types of Processes

Although there is no standard classification of types of processes in Linux. The segregation could be in interactive and non-interactive processes, foreground and background processes or daemon or batch processes. It can also be classified based on the status of the processes such as as zombie processes. It is good enough if we comprehend all these various terminologies in the linux system.

Interactive processes

An interactive process is one which needs user’s interaction while it is active. For example, when we launch a vi-editor, it is an interactive process. Another example could be the telnet command. Hence, the interactive processes have to be associated to a terminal.
Under the umbrella of interactive processes, we have Foreground and Background processes.
Lets discuss them one by one :

Foreground Process

A process is a foreground process if it is in focus and can be given input from the standard input. It blocks the shell until the foreground process is complete. When we run our commands on the terminal, they generally run as foreground processes. They block the terminal until it is complete. Although most of our linux commands are quick enough for us to even realise that.
Let us create our own program which sleeps for 10 seconds and then ourselves experience what waiting for the foreground process feels like.
The C source looks like:
#include 

#include 

int main()

{

    int time = 10;

    sleep(time);

    printf("Slept for 10 secs\n");

    return 0;

}
Now compile and run the program,
$ gcc wait_process.c -Wall -o wait_process

$ ./wait_process
What do you experience? The terminal is blocked by the running process, and not letting the user to do anything until the program is complete.
To check another foreground blocking, open the geditor through the terminal. The terminal launches the geditor, won’t let you input anything to the terminal until we terminate the geditor.

Background Process

Background processes are ones, that are running, but in the background, not taking any user input from the terminal. It doesn’t block the terminal, and allows us to use the terminal irrespective of the background process is complete or not. They key-character to make any new process to be run in background is ‘&’.
How we use this character, is by suffixing it with the command, as in,
 &
It is time, to run our ‘wait_process’ program to run as a background, so that we can avoid the terminal to get blocked while the process is sleeping.
$ ./wait_process &

[1] 2534

$
Whoahh! we get the command line back, to be able to use it and not to worry about the sleeping process.
To get these background and foreground handy, linux provides certain commands to view what is running and also switch any foreground process to background and vice versa.
One can use command ‘jobs’ to see what all is running associated with the terminal.
$gedit wait_process.c&

[1] 2538

$./wait_process&

[2] 2546

$jobs

[1]-  Running                 gedit wait_process.c &

[2]+  Running                 ./wait_process &

$
In the above exercise, we started two background processes – gedit and the wait_process program. Hence, the command ‘jobs’ lists both of them along with their PID’s.
If we want to switch the ‘geditor’ as a foreground process, use linux command ‘fg’
$fg
We see following after running the ‘fg’ command
gedit wait_process.c
And we again lose the command prompt. No points for guessing, now gedit is running as a foreground process. However, to switch it back as a background process, use key combinations ‘Ctrl + Z’ to suspend the process and then run the linux command ‘bg’
Note: When we suspend the process, it is not running and hence on resuming it will start with the same status, when it was stopped.
^Z

[1]+  Stopped                 gedit wait_process.c

$ bg

[1]+ gedit wait_process.c &

$
We got the command prompt back. We need to confirm if the geditor process is still up and running. It can be done by again using the command ‘jobs’
$jobs

[1]+  Running                 gedit wait_process.c &

Batch processes

These are the processes which are queued in and executed one by one in FIFO (First In First Out). Batch processes are not associated with any terminal instead given to the system to run, preferably when the system load is low or at a specific time. Low system load is a relative term, and hence it depends on the system and the type and requirements of the batch processes.
There are two linux commands which are provided to create the batch processes:

Linux at command

Usage, taken from man page
at [-V] [-q queue] [-f file] [-mldbv] TIME

at [-V] [-q queue] [-f file] [-mldbv] -t time_arg

at -c job [job...]

atq [-V] [-q queue]

atrm [-V] job [job...]
The ‘at’ command is used to schedule a process at a specific date/time. The time of today’s day is taken in the format HH::MM. However, it also accepts phrases like ‘today’, ‘tomorrow’, ‘teatime’, etc.
When we execute the ‘at’ command, we reach the ‘at’ prompt, where we can queue all the tasks/commands/programs in an order. When we are done with the queueing of the task, press key combination ‘Ctrl +d’. On pressing the key combination ‘Ctrl + d’, we see ‘EOT’ displayed at the standard output, following which we are back to our command prompt.
As an example,
$ at tomorrow

warning: commands will be executed using /bin/sh

at> ./wait_process

at> 

job 1 at Sun Mar 10 20:41:00 2013

Linux batch command

Usage, taken from man page
batch
This command launches the process when the system load is low i.e. load average drops below 0.8, or the value set by atd
It’s usage example is similar to the command ‘at’ (explained above).

Daemon Processes

A daemon process in Linux is also one of its kind which runs in background. However, what is different here is, daemon processes are not associated to any terminal in any way. Therefore such processes don’t take interact with the user. A widespread example of daemon process is a server service of any kind. For example, if we consider a mail server, it just have to listen to the relevant ports and respond with its protocol routines on receiving packages. So, such kind of processes can be run as daemon processes, independent of terminal and user interaction.
Generally, when we code any program in C in Linux and execute it, the terminal becomes its parent process. Hence, in order to develop a daemon process service, the programmer needs to detach the process from its parent process. This is done by killing its parent process, which makes the process independent of the terminal, but controlled by its grandparent process i..e init process.
We shall learn more about coding a daemon process in the second part of the article.

Zombie Processes

When a process terminates, there is a proper exit and cleanup routine to be done by the developer of the program. If there is a bug, such that cleanup could not happen appropriately, though the process has been killed. Now, this process do occupy some memory, but will never be scheduled by the scheduler as the process status is ‘terminated’.
Such processes are called zombie processes, which are killed but still exist.
Zombie processes are generally harmless if there are not much. However, if we have a whole lot of zombie processes lingering, then it could be a pain. Since, the PID’s still taken up by the zombie processes are not available for re-allocation to new processes. Hence, soon the system would be out of available PID’s if the zombie processes keep on increasing, and no new process would be able be launch.

The init process

The init process is the one which initiates system processes taken from the script
/etc/inittab
and has been assigned PID = 1. So, these system processes include setting up the user space, mounting file systems, set up everything to get the system up and running. Worth mentioning, it is the init process which is at the apex of the complete process tree. It is run as root, and is the parent process of a user shell. It is the last sequence in the booting and is the one, which launches and controls the shutdown.

Process States

Linux processes generally go through six major states, which are listed below:
1. Running or Runnable ( R ) – A running state has a broader concept here. Running always does not mean utilising the CPU. Even while a process is ready to run, the state is running state.
Hence, there are two sub-states, when the process is queued in the ready queue to run and when the process is actually being executed, it is in the executing sub-state as has been scheduled by the scheduler.
2. Stopped (T) – If a running process receives a stop signal, it is moved to the stopped state. A process can also be in stopped state if it has been halted by a trace while debugging. .
3. Uninterruptible sleep (D) – It is a sleeping state, process has been blocked. Mostly, process goes into an uninterruptible sleep during an IO operation.
4. Interruptible sleep (S) – It is a sleeping state i.e. a blocking state where the process is waiting for an event to occur.
5. Zombie/Defunct state(Z) – It is the process state in which process has been terminated but not reaped by its parent process.
6. Dead (X) – A process never reaches this state, as as soon as it is dead, it is gone.
Note: For BSD formats and when the stat keyword is used, additional characters may be displayed:
  • < high-priority (not nice to other users)
  • N low-priority (nice to other users)
  • L has pages locked into memory (for real-time and custom IO)
  • s is a session leader
  • l is multi-threaded (using CLONE_THREAD, like NPTL pthreads do)
  • + is in the foreground process group.
A simplified life cycle of a Linux process is illustrated through following diagram:
Linux_process_states












In order to check the current status of the active processes at a moment on the linux system, we again use the ‘ps’ command but with a different set of options.
$ps ax
In my system, I again get a huge list of processes. However, we are interested in the status details of the listed processes, therefore here is a snapshot of the output
 PID TTY      STAT   TIME COMMAND

1779 pts/0    Ss     0:00 bash

1797 ?        Sl     0:00 telepathy-indicator

1805 ?        Sl     0:00 /usr/lib/telepathy/mission-control-5

1809 ?        Sl     0:00 /usr/lib/gnome-online-accounts/goa-daemon

1851 ?        Sl     0:03 gnome-screensaver

1891 ?        Sl     0:04 update-notifier

1936 ?        S      0:00 /usr/bin/python /usr/lib/system-service/system-service-d

1940 ?        Sl     0:00 /usr/lib/deja-dup/deja-dup/deja-dup-monitor

2091 ?        SNl    0:00 deja-dup --prompt

2129 ?        Sl    21:54 /usr/lib/firefox/firefox

2145 ?        Sl     0:00 /usr/lib/i386-linux-gnu/at-spi2-core/at-spi-bus-launcher

2724 ?        S      0:00 /usr/lib/cups/notifier/dbus dbus://

2801 ?        SNl    0:22 /usr/bin/python /usr/bin/update-manager --no-focus-on-map

3157 ?        S      0:00 [kworker/0:1]

3168 ?        S      0:00 [kworker/0:2]

3207 ?        S      0:00 [kworker/0:0]

3208 pts/0    R+     0:00 ps ax
Observer the status of the list of processes under column ‘STAT’. Although, we have more confidence on Linux commands than anything, but it is exciting to confirm from the process ‘ps’ (at the end). Its status is ‘R+’ as we can read from the above output snapshot, which indicates it is running and running as a foreground process. So true!

Real time snapshot of processes

The ‘ps’ command that we just discussed in the previous section, evinces the active process list at a particular moment when the command is executed. In many cases, it is a need of the hour to view dynamic real time running of the processes. For such circumstances, linux comes with the ‘top’ command.
The ‘top’ usage looks like
top -hv | -bcHisS -d delay -n iterations -p pid [, pid ...]
More details can be found at its man page
To see how and what all it provides, here is an output snapshot from my ubuntu system
The command:
$top
Output:
top - 10:16:34 up 1 day, 17:36,  1 user,  load average: 1.51, 0.99, 0.84

Tasks: 136 total,   1 running, 135 sleeping,   0 stopped,   0 zombie

Cpu(s): 28.8%us,  3.3%sy,  0.0%ni, 67.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

Mem:    507536k total,   498516k used,     9020k free,    10488k buffers

Swap:   521212k total,   187996k used,   333216k free,    91572k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                      

2129 ubuntu    20   0  727m 258m  10m S 27.1 52.1 113:12.30 firefox                                      

 918 root      20   0  116m  35m 2128 S  3.3  7.1   7:33.90 Xorg                                         

1772 ubuntu    20   0 89352 5264 2940 S  0.7  1.0   0:08.13 gnome-terminal                               

1496 ubuntu    20   0  142m 3036 1920 S  0.3  0.6   1:20.55 metacity                                     

3782 root      20   0     0    0    0 S  0.3  0.0   0:00.57 kworker/0:0                                  

3800 ubuntu    20   0  2836 1152  880 R  0.3  0.2   0:00.05 top                                          

    1 root      20   0  3512 1160  604 S  0.0  0.2   0:00.66 init                                         

    2 root      20   0     0    0    0 S  0.0  0.0   0:00.02 kthreadd                                     

    3 root      20   0     0    0    0 S  0.0  0.0   0:07.52 ksoftirqd/0                                  

    5 root      20   0     0    0    0 S  0.0  0.0   0:00.36 kworker/u:0                                  

    6 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0                                  

    7 root      RT   0     0    0    0 S  0.0  0.0   0:02.89 watchdog/0                                   

    8 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 cpuset                                       

    9 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 khelper                                      

  10 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kdevtmpfs                                    

  11 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 netns                                        

  12 root      20   0     0    0    0 S  0.0  0.0   0:00.79 sync_supers                                  

  13 root      20   0     0    0    0 S  0.0  0.0   0:00.02 bdi-default                                  

  14 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 kintegrityd                                  

  15 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 kblockd                                      

  16 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 ata_sff                                      

  17 root      20   0     0    0    0 S  0.0  0.0   0:00.03 khubd                                        

  18 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 md                                           

  21 root      20   0     0    0    0 S  0.0  0.0   0:00.12 khungtaskd                                   

  22 root      20   0     0    0    0 S  0.0  0.0   0:08.45 kswapd0                                      

  23 root      25   5     0    0    0 S  0.0  0.0   0:00.00 ksmd                                         

  24 root      20   0     0    0    0 S  0.0  0.0   0:00.00 fsnotify_mark                                

  25 root      20   0     0    0    0 S  0.0  0.0   0:00.00 ecryptfs-kthrea                              

  26 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 crypto                                       

  34 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 kthrotld                                     

  35 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kworker/u:2                                  

  36 root      20   0     0    0    0 S  0.0  0.0   0:00.08 scsi_eh_0                                    

  38 root      20   0     0    0    0 S  0.0  0.0   0:00.00 scsi_eh_1                                    

  39 root      20   0     0    0    0 S  0.0  0.0   0:00.03 scsi_eh_2
Checking out running the linux ‘top’ command, we’ll observe that the output keeps on changing with every moment, as the process dynamics keep on changing at real time. This is possible, as the ‘top’ command is running all this while and monitoring the running tasks. Hence, we need to terminate the ‘top’ process to get back the command prompt.
Analysing and trying to understand the ‘top’ command output, let us go line by line.
top - 10:16:34 up 1 day, 17:36,  1 user,  load average: 1.51, 0.99, 0.84
Going in order from left to right, it indicates -
  • current time
  • time since the machine is on
  • the number of users logged in
  • average load on the system specifying three values for last one minute, last five minutes and last fifteen minutes respectively.
Coming to the next row of output, which looks like
Tasks: 136 total,   1 running, 135 sleeping,   0 stopped,   0 zombie
It helps us know how many total processes are there, which are 136 in our case, which includes one in the running state, 135 are in the sleeping state, zero in the stopped and zero zombie processes.
Now we know what all processes have been launched and are in which states.
Moving on,
Cpu(s): 28.8%us,  3.3%sy,  0.0%ni, 67.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
This row indicates the CPU usage in percentages. As in,
  • 28.8%us – CPU percentage for user processes
  • 3.3%sy – CPU percentage for system processes
  • 0.0%ni – CPU percentage for processes with ‘nice’ priority
  • 67.9%id – idle CPU percentage
  • 0.0%wa – CPU percentage for processes waiting for I/O
  • 0.0%hi – CPU percentage for processes serving hardware interrupts
  • 0.0%si – CPU percentage for processes serving software interrupts
  • 0.0%st – It is the steal time i.e. percentage CPU time stolen from a virtual machine i.e. time in an involuntary wait by a virtual machine, while the hypervisor is servicing another process.
The next row in the output specifies physical memory usage
Mem:    507536k total,   498516k used,     9020k free,    10488k buffers
The information is in terms of total physical memory available, where how much has been used, how much is free and how much is used for buffers.
On similar lines, the next output states usage of swap space
Swap:   521212k total,   187996k used,   333216k free,    91572k cached
Then following rows list all the details of all the launched processes at real time. What each detail means is:
  • PID – The process ID
  • USER – The user which owns the process
  • PR – Process priority value
  • NI – The nice value of a process.
  • VIRT – The virtual memory used by the process
  • RES – Physical memory used
  • SHR – Shared memory of the process
  • S – The status of the process where S – Sleeping : R – Running : Z- Zombie
  • %CPU – Percentage CPU utilization of the process
  • %MEM – Percentage memory usage of the process
  • (TIME+)  – The total activity time of the process
  • COMMAND – The command used to launch the process.

Terminating the processes

The linux system allows its users to terminate any process, of course with due considerations to access permissions. The linux user can terminate a process using command ‘kill’.
The usage syntax
kill [ -signal | -s signal ] pid ...

      kill [ -L | -V, --version ]

      kill -l  [ signal ]
More details found in its man page
The ‘kill’ linux command sends a signal to the specified process. Which process to send the signal is specified by its PID.
There are standard numbers assigned to each set of signals. We can get the information of what number is corresponding to which signal using the same ‘kill’ command through ‘-l’ option.
$ kill -l

1) SIGHUP     2) SIGINT     3) SIGQUIT     4) SIGILL     5) SIGTRAP

6) SIGABRT     7) SIGBUS     8) SIGFPE     9) SIGKILL    10) SIGUSR1

11) SIGSEGV    12) SIGUSR2    13) SIGPIPE    14) SIGALRM    15) SIGTERM

16) SIGSTKFLT    17) SIGCHLD    18) SIGCONT    19) SIGSTOP    20) SIGTSTP

21) SIGTTIN    22) SIGTTOU    23) SIGURG    24) SIGXCPU    25) SIGXFSZ

26) SIGVTALRM    27) SIGPROF    28) SIGWINCH    29) SIGIO    30) SIGPWR

31) SIGSYS    34) SIGRTMIN    35) SIGRTMIN+1    36) SIGRTMIN+2    37) SIGRTMIN+3

38) SIGRTMIN+4    39) SIGRTMIN+5    40) SIGRTMIN+6    41) SIGRTMIN+7    42) SIGRTMIN+8

43) SIGRTMIN+9    44) SIGRTMIN+10    45) SIGRTMIN+11    46) SIGRTMIN+12    47) SIGRTMIN+13

48) SIGRTMIN+14    49) SIGRTMIN+15    50) SIGRTMAX-14    51) SIGRTMAX-13    52) SIGRTMAX-12

53) SIGRTMAX-11    54) SIGRTMAX-10    55) SIGRTMAX-9    56) SIGRTMAX-8    57) SIGRTMAX-7

58) SIGRTMAX-6    59) SIGRTMAX-5    60) SIGRTMAX-4    61) SIGRTMAX-3    62) SIGRTMAX-2

63) SIGRTMAX-1    64) SIGRTMAX
The most commonly used signal to terminate processes is
9) SIGKILL
Now, as an example experience, we shall be creating a process and terminate it.
We’ll use our old program source, and its executable.
$ ./wait_process &

[1] 3315

$ ps

 PID TTY          TIME CMD

1779 pts/0    00:00:00 bash

3315 pts/0    00:00:00 wait_process

3316 pts/0    00:00:00 ps

$ kill -9 3315

[1]+  Killed                  ./wait_process

$ ps

 PID TTY          TIME CMD

1779 pts/0    00:00:00 bash

3317 pts/0    00:00:00 ps
In the above practical exercise, we ran our waiting process, and killed it before it got complete.

References

http://www.advancedlinuxprogramming.com
http://careers.directi.com/display/tu/Understanding+Processes+in+Linux

Baca Selengkapnya ....
Categories:

SIGALRM Timers and Stdin Analysis

Posted by Unknown Rabu, 27 Maret 2013 0 komentar
http://www.linuxjournal.com/content/sigalrm-timers-and-stdin-analysis


 It's not hard to create functions to ensure that your script doesn't run forever. But what if you want portions to be timed while others can take as long as they need? Not so fast, Dave explains in his latest Work the Shell.
In an earlier article, I started building out a skeleton script that would have the basic functions needed for any decent shell script you might want to create. I started with command-line argument processing with getopts, then explored syslog and status logging as scripts. Finally, I ended that column by talking about how to capture signals like Ctrl-C and invoke functions that can clean up temp files and so on before actually giving up control of your shell script.
This time, I want to explore a different facet of signal management in a shell script: having built-in timers that let you specify an allowable quantum of time for a specific function or command to complete with explicit consequences if it hangs.
When does a command hang? Often when you're tapping into a network resource. For example, you might have a script that looks up definitions by handing a query to Google via curl. If everything's running fine, it'll complete in a second or two, and you're on your way.
But if the network's off-line or Google's having a problem or any of the million other reasons that a network query can fail, what happens to your script? Does it just hang forever, relying on the curl program to have its own timeout feature? That's not good.

Alarm Timers

One of the most common alarm timer approaches is to give the entire script a specific amount of time within which it has to finish by spawning a subshell that waits that quantum, then kills its parent. Yeah, kinda Oedipal, but at least we're not poking any eyes out in this script!
The additional lines end up looking like this: 

(
sleep 600           # if 10 minutes pass
kill -TERM $$       # send it a SIGTERM signal
)&

There's no "trap" involved—easy enough. Notice especially that the closing parenthesis has a trailing ampersand to ensure that the subshell is pushed into the background and runs without blocking the parent script from proceeding.
A smarter, cleaner way to do this would be for the timer child subshell to send the appropriate SIGALRM signal to the parent—a small tweak: 

(
sleep 600            # if 10 minutes pass
kill -ALRM $$        # send it a SIGALRM signal
)&

If you do that, however, what do you need in the parent script to capture the SIGALRM? Let's add that, and let's set up a few functions along the way to continue the theme of useful generic additions to your scripts: 

function allow_time
{
   ( echo timer allowing $1 seconds for execution
     sleep $1
     kill -ALRM $$
   ) &
}

This first function lets you easily set a time for subsequent execution, while the second presents your ALRM handler in a bit neater fashion: 

function timeout_handler
{
   echo allowable time for execution exceeded.
   exit 1
}

Note that both scripts have debugging output that's probably not needed for actual production code. It's easily commented out, but running it as is will help you understand how things interact and work together.
How might this be used? Like this: 

trap timeout_handler SIGALRM
allow_time 10
code that has ten seconds to complete

That would give the script ten seconds to finish.
The problem is, what happens if it finishes up in less time than allotted? The subshell is still out there, waiting, and it pushes out the signal to a nonexistent process, causing the following sloppy error message to show up: 

sigtest.sh: line 7: kill: (10532) - No such process

There are two ways to fix this, either kill the subshell when the parent shell exits or have the subshell test for the existence of the parent shell just before it sends the signal.
Let's do the latter. It's easier, and having the subshell float around for a few seconds in a sleep is certainly not going to be a waste of computing resources.
The easiest way to test for the existence of a specified process is to use ps and check the return code, like this: 

ps $$ >/dev/null ; echo $?

If the process exists, the return code will be 0. If it's gone, the return code will be nonzero. This suggests a simple test: 

if [ ! $(ps $$ > /dev/null) ]

But, that won't work because it's the return code, not what's handed to the shell. The solution? Simply invoke the ps command, then have the expression test the return code: 

function allow_time
{
   ( echo timer allowing $1 seconds for execution
     sleep $1
     ps $$ > /dev/null
     if [ ! $? ] ; then
       kill -ALRM $$
     fi
   ) &
}

That solves that problem. But, what if you have sections of code where you want to limit your execution time followed by other sections where you don't care?
That's easy if you don't mind leaving some child processes around waiting to shoot a signal at the parent. Just use this: 

trap '' SIGALRM

when you're done with the timed passage. What happens is that the timer generates a signal, but the parent script ignores it.
The limitation on this, of course, is if you have code like this: 

regular code
possible runaway code <-- 100="" allocate="" cancel="" code="" more="" possible="" regular="" runaway="" seconds="" timer="">

The situation arises if the second code block is started before the first timer runs out. Imagine that you've allocated 100 seconds for the first timed block and it finishes in 90 seconds. Regular code takes five seconds, then you're in block two, for exactly ten seconds. Then the first ALRM timer triggers, after ten seconds rather than another 100. Not good.
This is admittedly a bit of a corner case, but to fix it, let's reverse the decision about having child processes test for the existence of the parent before sending the signal and instead have the parent script kill all child subshells upon completion of the timed portion. It's a bit tricky to build, because it requires the use of ps and picks up more processes than just that subshell, so you not only need to screen out your own process, you also want to get rid of any subshell processes that aren't actually the script itself.
I use the following: 

ps -g $$ | grep $myname | cut -f1 -d\  | grep -v $$

This generates a list of process IDs (pids) for all the subshells running, which you then can feed to kill: 

pids=$(ps -g $$ | grep $myname | cut -f1 -d\  | grep -v $$)
kill $pids

The problem is that not all of those processes are still around by the time they're handed to the kill program. The solution? Ignore any errors generated by PID not found: 

kill $pids > /dev/null 2>&1

Combined as a function, it'd look like this: 

function kill_children
{
   myname=$(basename $0)
   pids=$(ps -g $$ | grep $myname | cut -f1 -d\  | grep -v $$)
   kill $pids > /dev/null 2>&1
}

If you're thinking "holy cow, multiple timers in the same script is a bit of a mess", you're right. At the point where you need something of this nature, it's quite possible that a different solution would be a smarter path.
Further, I'm sure there are other ways to address this, in which case I'd be most interested in hearing from readers about whether you've encountered a situation where you need to have multiple timed portions of your code, and if so, how you managed it! Send e-mail via http://www.linuxjournal.com/contact.

Baca Selengkapnya ....
Categories:

Mastering the Linux Shell : Files and Directories

Posted by Unknown Senin, 25 Maret 2013 0 komentar
http://marcelgagne.com/content/mastering-linux-shell-files-and-directories


Let me tell you the secret of computers, of operating systems, and of the whole industry that surrounds these things: Everything is data. Information is the be all and end all of everything we do with computers. Files are the storehouses for that information and learning how to manipulate them, use and abuse them, and otherwise play with them will still be the point of computers 20 years from now. There's a saying in the Linux world that "everything is a file" (a comment attributed to Ken Thompson, the developer of UNIX). That includes directories. Directories are just files with lists of files inside them. All these files and directories are organized into a hierarchical file system, starting from the root directory and branching out.
For the record, and to make things easier, you can safely assume that folders and directories are the same thing. The terms can be used interchangeably, but I will usually refer to them directories. If you are more comfortable thinking of them as folders, don't worry. Depending on the application, you'll see both terms used.
The root directory (referred to as slash, or /) is actually aptly named. If you consider your file system as a tree's root system spreading out below the surface, you start to get an idea of just what things look like.
Under the root directory, you'll find folders called usr, bin, etc, tmp, and so on.  And then we have the three invisible, often overlooked, but completely indispensible files on your system: standard in, standard out, and standard error. I'll tell you more about those three later. Suffice it to say that understanding and knowing how to work with all these “files” will provide you with amazing flexibility when it comes to doing your work.

File Naming Conventions

Valid filenames may contain almost any character. You do have to pay some attention to the names you come up with. Your Linux system will allow filenames up to 255 characters in length. How you define filenames can save you a lot of hassle, as I will soon demonstrate.
Some valid filename examples include the following:
fish
duck
program_2.01
a.out
letter.to.mom.who.I.dont.write.often.enough.as.it.is
.bash_profile
Notice the last name in particular. It starts with a period. Normally, this type of file is invisible with a default listing. Starting a file name with a period is a way to make a file somewhat invisible.  This is good to know if you don't want to burden file listings with a lot of noise.  It is also the way that a cracker (or hacker, if you prefer) might hide his or her tracks should they break into your system -- by creating a directory that starts with a period.  To see they so-called dot-files, use the ls command with a -a flag (ls -a).  Two particularly interesting directories are:
.     (dot) Your current directory
..    (dot dot) The parent directory
As you can see, they are, by default, invisible because they start with a period. To see them, you need to use "ls -a". And now that I've brought up listing files, let's examine the ls command.

Listing Files with Emotion!

The ls command seems so simple, and yet it has a number of options that can give you tons of information. Change to something like the /etc directory and try these options. The cd command is how you change directory.
cd /etc
ls --color
ls –b
ls –lS
ls –lt
The first listing will show different types of files and directories in color. The second (-b) will show octal representations for files that might have been created with control characters. Depending on the terminal you are using, the default is to show question marks or simply blanks. If you need to access (or delete) the file, it helps to know what it is really called. The third and fourth options control sorting. The -ls option gives you a long listing (lots of information) sorted by file size. The last option (-lt) sorts by time with the newest files at the top of the list and the oldest at the bottom.
We started this by changing directory to /etc.  If you ever want to know what directory you are in, one way is to look at your bash command line prompt as it sometimes displays where you are.  But that's not always true. A sure fire way is the pwd command.
$ pwd
/etc/thunderbird
Here's a cool trick. To go back to the last directory (or folder) you were in, try the following.
cd -
The hyphen is a special character that references your last position in the file system. Here's another cool one.
cd ~
That will take you home, to your own personal starting directory. The tilde means "home". More on this later in the series. Just typing 'cd' will do the same, but the tilde is an important substitution character. Speaking of which . . .

A Peek at Metacharacters

Metacharacters are special characters that have particular meaning to your shell, that dollar sign or hash mark prompt where you do your work. The two I want to look at are the asterisk and the question mark. The following is what they mean to the shell.
*      Match any number of characters
?      Match a single character
Extending our talk of listing files, you could list all files containing “ackle” by using this command:
$ ls *ackle*
hackle hackles tackles
Similarly, you could find all the words that start with an “h” like this:
$ ls h*
hackle hackles
Now, if you want to see all the seven-letter words in your directory, use this command:
$ ls ???????
hackles tackles
Each question mark represents a single letter position.
And that is where I will leave this discussion for today. Join me next Monday for part three in this series. Remember that you can also follow the action on CookingWithLinux.com where it's all Linux, all the time. Except for the occasional wine review.
A votre santé! Bon appétit!

Baca Selengkapnya ....
Categories:

Clonezilla vs. FOG: The clone wars

Posted by Unknown 0 komentar
http://www.openlogic.com/wazi/bid/275172/clonezilla-vs-fog-the-clone-wars


Computer cloning, also referred to as ghosting or imaging, involves setting up the operating system, drivers, software, and data on one computer, then automatically replicating the same setup on other computers. Clonezilla Server Edition and FOG are the most popular open source cloning systems. While both do similar jobs – clone and restore machines over the network using tools and services such as partimage, tftp, and PXE – they go about it very differently. Which is right for you depends on your network's configuration and composition.
The most visible difference between the two solutions is in their user interfaces. Clonezilla has an archaic ncurses-based interface, while FOG provides a web-based interface that you can access from any computer on the network. It also has a special UI that lets you deploy images from mobile devices.
fog UI resized 600
While both FOG and Clonezilla SE can handle multiple images, FOG is better designed to manage multiple images. With FOG you can logically arrange images in groups, such as Accounts Department or Labs or Lounge. FOG also scales better; it features a storage manager that can control a group of NFS servers that all host images. Multiple servers can serve images, taking some of the stress off the main FOG server and speeding up cloning, especially in large networks.
In an enterprise where you have a large number of computers to deploy, the best course is to deploy images across the network, which requires setting up a dedicated cloning server. For Clonezilla SE, this means setting up a Diskless Remote Boot in Linux (DRBL) server by installing it on top of a Debian or CentOS server. If you manage a small network and don't want to earmark a computer as a permanent DRBL server, you can use the DRBL live CD to convert any machine into a server temporarily to broadcast images created by Clonezilla and stored on a local disk to any computer on the network.
To use a cloning solution effectively, it's best if computers on your network have similar hardware components. If your network is made up of computers with different components, you'd need to manage lots of different images.
As for FOG, its installation script creates the components required for an imaging server on top of a standard LAMP server. Unlike Clonezilla's DRBL server, the FOG server is designed to integrate with existing network infrastructure such as DHCP and DNS servers, although it can also set these up on its own. Setting up a FOG cloning server is pretty straightforward, but if you're using an existing DHCP server you must tweak it to forward PXE traffic to the FOG server, and configure the firewall to pass traffic to the server.
If all of the machines you want to image are not on your network, you need a solution that can clone offline machines as well. To do that, you create a master image, copy it on to a removable USB disk, and deploy from that. Clonezilla lets you save an image to a disk and then clone it either over the network or by physically going over to the computer. FOG doesn't – you can clone only from an imaging server.
After an image has been deployed, both Clonezilla SE (with DRBL-Winroll) and FOG (with its client service) can integrate the cloned machines into an Active Directory domain.
Other cloning options
Clonezilla SE and FOG are designed for cloning and deploying multiple computers over a network, but they both require setting up a dedicated server. This is overkill for situations where you just need to quickly image a disk, as you would for example when switching to a bigger hard drive. In such a situation, you might consider using one of these open source disk cloning applications:
  • Mondo Rescue – This tool is available in the repos of major desktop distros and can clone your computer to tapes, hard disks, USB devices, and NFS mounts. Unlike other tools, Mondo creates a specialized recovery live CD/DVD based on its own Mindi distro, customized for the computer being backed up.
  • Redo Backup and Recovery – Perhaps the easiest point-and-click cloning solution with a good-looking graphical interface. It can save cloned images on a disk attached to a computer or a network folder. The live CD also has tools such as testdisk and photorec to recover files. Its only limitation is that it's very sensitive to hardware changes and will restore only to identical hardware.
  • Trinity Rescue Kit – Popularly known as TRK, the live distro is primarily designed for rescuing and repairing Windows installations. It's chock-full of tools that can reset forgotten passwords, recover accidentally deleted files and partitions, and scan for viruses and rootkits. Additionally, you can also use the distro to clone Windows machines over the network.
While that's just about the extent of Clonezilla's capabilities, the FOG service can do a lot more. It can schedule tasks, such as deploying images, from its web interface, and perform several tasks other than imaging, such as installing and managing printers, tracking access to cloned machines, powering up a computer remotely using Wake-On-LAN, and installing applications remotely via a feature called snap-ins.
With snap-ins you can directly push the executable installer for a simple application to a Windows computer. For a larger application such as Microsoft Office that requires multiple files for installation, you need to use a tool like SFX Maker instead. FOG snap-ins don't have to be associated with an imaging task, so they can be used for things such as pushing software updates to client computers.
If you don't need to keep track of machines after cloning them, as might be the case, for example, in a repair or service center, Clonezilla gives you an edge over FOG. With Clonezilla you don't need to register a host with the server before it can be cloned. In contrast, FOG, by default, not only requires hosts to be registered before they are imaged, it also needs to register clients before it deploys images to them – though by using the Capone plugin you can override FOG's default behavior and clone a computer without first registering it with the server. Registering hosts has advantages, however, especially on enterprise networks. While registering hosts, FOG records the unique MAC address of their network cards, which reduces the chance of mistakenly deploying an image to the wrong machine.
While FOG is a fine enterprise imaging solution, it also has many of the features you'd want from a network management app. For example, in addition to options for registering and deploying an image, FOG's menu offers options to wipe a disk, restore deleted files, scan a disk for bad blocks, and run a virus scan using ClamAV.

Final word

If you're choosing between Clonezilla and FOG and you have machines that aren't connected to a network, you have no option but to use Clonezilla. You have to take an image with you and deploy it on each machine, but that's still faster than preparing each disk and installing and setting up an operating system on each individual client.
Clonezilla SE makes the most sense for networks with clients that don't require much administration after being imaged, such as those in Internet cafes, libraries, and school labs. If you need to look after machines after they've been cloned, it's best to go with FOG. Its post image options are excellent, and you can deploy machines without leaving your own desk.
The bottom line is that, while Clonezilla works best for offline computers and individuals, FOG has all the features you need to manage and deploy images in an enterprise.

Baca Selengkapnya ....
Categories:

How to deploy Piwik Web Analytics on OpenShift Online

Posted by Unknown 0 komentar
http://www.linuxbsdos.com/2013/03/21/how-to-deploy-piwik-web-analytics-on-openshift-online


Piwik Web Analytics is a Free Software traffic analytics application for Web publishers. If you have the resources to run your own, it is a good replacement for Google Analytics. It is a database-driven, PHP application that you can download and install on your Web hosting account. There is also a hosted service provided by Arvixe.
If you have a Web hosting account, but not enough resources to host Piwik, OpenShift Online presents an alternative platform to host it on. OpenShift Online is a cloud computing Platform as a Service (PaaS) provided by Red Hat, Inc. If you are new to OpenShift, you may want to review OpenShift Online: A non-developer’s guide.
This article, the second on OpenShift, shows how to deploy Piwik on a FreeShift account, the free service component of OpenShift Online.
If you don’t yet have an account, you may sign up for one here. After signing up and verifying the account, you may start using and deploying applications via a Web interface or by using the command-line OpenShift Client Tools (RHC) from any supported operating system. Linux, Mac OS X, and Windows are currently supported.
OpenShift Online Web Console
The Web interface is really nice, but I find that the easiest method for deploying an application initially is via RHC. That requires installing the client control application on the operating system you are using. In this article, the steps to install and use it from Fedora and Ubuntu are given. For Windows or Mac OS X installation guide, please see this installation guide.
After setting up a new account, one of the first things you do from the Web management interface is create a namespace. Your account will have a .rhcloud.com URL, which will be accessible from yourNamespace.rhcloud.com. so your namespace is like a subdomain of rhcloud.com. That’s a very simplified way of explaining it, but I think it gets the point across better than spewing more technical jargon. Any application you create will be accessible from Appname-yourNamespace.rhcloud.com.
I deployed Piwik from a Fedora 18 installation, but you can do it from any other Linux distribution. The client tools are Ruby applications, so you’ll need to install it and everything else that it needs to run. Plus, Git will have to be installed, because that’s what will be used to push or deploy the app to your OpenShift Online account.
So after creating and configuring a new account, here are the steps required to create and deploy Piwik:
1. Install the requirements: Ruby 1.8.7 (or later) and Git are required. To install them on Fedora 18, you just need one command – yum install rubygem-rhc git. Or if you installed and prefer using Dnf, type dnf install rubygem-rhc git. That will install Ruby, the RHC tools and Git. On Ubuntu, you need two commands to achieve the same thing. First, type sudo apt-get install rubygems git, then gem install rhc.
2. Create and deploy Piwik: Now that you have all the requirements in place, the next step is to create and deploy the applications to your OpenShift Online account. Doing this involves creating a PHP app on your account. (Piwik is a PHP applications.). Then adding a (MySQL) database cartridge, cloning the Piwik repository, and pushing it to your OpenShift account. (Steps for doing this were taken from the official Piwik OpenShift quickstart guide.) You may want to visit that guide, then come back to step 3 of this tutorial when you are done.
The next five screen shots show how the process unfolded on my Fedora 18 computer.
Run the command rhc setup to start the setup wizard. This assumes that you have already created and configured your account, so what you have to do here is login.
OpenShift Online Setup PaaS
Authentication between your computer and your OpenShift account is accomplished using SSH keys. The first time you run rhc setup, the keys will be created and the public key uploaded to your account. After this, you may log into your account via ssh. The instruction will be on the Web management interface.
OpenShift PaaS
Next. Create the application using the commands in this screen shot. The “-a” switch is used to specify the name of the application, while the “-t” is used to specify the Web framework (cartridge) the application will use.
OpenShift PaaS Create App
Piwik is database-driven, so you need to add a MySQL cartridge using the commands shown in this screen shot. Make note of the name, username, and password of the database created here, because you’ll need them to setup and Piwik later. To make it easier to manage the MySQL databases you create in your account, I highly recommend that you create a phpMyAdmin cartridge from the Web Management interface. Creating one on my account made it easy to identify the source of a show-stopper error during the final step of this exercise.
OpenShift PaaS Create cartridge
The foregoing should have created a “piwik/php” directory where you’ve been running the commands. So you need to change into the piwik/php directory, make sure its empty (run rm -rf *), then clone the Piwik Git repository using these commands: 
git remote add upstream -m master git://github.com/openshift/piwik-openshift-quickstart.git
git pull -s recursive -X theirs upstream master
.
Finally, push the cloned repo to your OpenShift account using the git push command. You’ll be promoted to enter a commit message. Note that you’ll be entering the message via Vi, so you need to enter edit mode by hitting the a, i, or o keys. Type the message, then press the Esc key to exit edit mode. After that, save and quit by using the following character sequence :wq. That takes care of step 2. You will be given the URL of your applications, which should take for form: piwik-yourNamespace.rhcloud.net. For the final step, you need to access that URL and install Piwik.
OpenShift
3. Setup and configure Piwik: When you access Piwik’s URL, you will see something like this screen shot. Click Next.
Piwik Web analytics
This is where you input the database name, username and password that was created in the previous step. It was supposed to be the easiest step, but it improved otherwise. By default, the database server is referenced by the server’s loopback address, which is always 127.0.0.1.
Piwik database
Specifying the database credentials and clicking Next produced the error message shown in this screen shot.
Piwik error
Changing the loopback address to localhost, which means the same thing, produced a different error message.
Piwik Web analytics error
Using the server’s routable IP address produced yet a different error message. A search of the knowledgebase and googling did not give me a solution that worked, so I accessed phpMyAdmin to see what I could find.
Piwik Web analytics error
This screen shot shows what I found on phpMyAdmin. For some reason, a duplicate of the username was created with an actual IP address. Specifying the IP address I found here in place of localhost or the loopback address solved the problem.
Piwik Web Analytics phpMyAdmin
So there you have it. I now have Piwik running on a FreeShift account on OpenShift Online, which I use to monitor traffic on this website. Saves me from running it on my VPS account. Besides the RAM and disk space quota, one small gear also has a 40,000-file limitation. But that’s not something to worry about here, because this setup has generated just 3287 files.
Piwik realtime statistics stats
This just shows how a non-developer can take advantage of a developer-targeted service like OpenShift. Piwik is just one of many ready-made applications you can deploy on OpenShift. View the complete list here.

Baca Selengkapnya ....
Categories:
Trik SEO Terbaru support Online Shop Baju Wanita - Original design by Bamz | Copyright of android japan.
Diberdayakan oleh Blogger.