How to Rollback Package Updates/Installation on Fedora /RedHat/ CentOS

Fedora 14, like FC14, uses yum for package management. yum is built on top of rpm, and pirut, pup, and yumex are graphical interfaces built on top of yum. Together, these tools provide a simple-to-use, powerful package management system.

One of the least-known secrets about rpm is that it can rollback (undo) package changes. It can take a fair bit of storage space to track the information necessary for rollback, but since storage is cheap, it's worthwhile enabling this feature on most systems.

Here's cut-to-the-chase directions on using this feature:

1. To configure yum to save rollback information, add the line tsflags=repackage to /etc/yum.conf.


2. To configure command-line rpm to do the same thing, add the line %_repackage_all_erasures 1 to /etc/rpm/macros.


3. Install, erase, and update packages to your heart's content, using pup, pirut, yumex, yum, rpm, and the yum automatic update service.


4. If/when you want to rollback to a previous state, perform an rpm update with the --rollback option followed by a date/time specifier. Some examples: rpm -Uhv --rollback '3:00 pm', rpm -Uhv --rollback '4 hours ago', rpm -Uhv --rollback 'March 25'.

Top Command Linux

When you need to see the running processes on your Linux in real time, you have top as your tool for that.

top also displays other info besides the running processes, like free memory both physical and swap

Usage

top [options]

Options

-d ss.tt

Delay -- Specifies the seconds and tenths of seconds of delay between the updates of the info showed on the screen, being the default 3 seconds

-i

Starts top with the last remembered 'i' state reversed. When this toggle is Off, tasks that are idled or zombied will not be displayed.

-n n

Specifies the maximum number of iterations, or frames, top should produce before ending.

-p n

Monitor only processes with specified process IDs. This option can be given up to 20 times, or you can provide a comma delimited list with up to 20 pids. Co-mingling both approaches is permitted. This is a command-line option only. And should you wish to return to normal operation, it is not necessary to quit and and restart top -- just issue the '=' interactive command.

-s

- Secure - Runs top in secure mode, restricting the commands you can use while top is running even for root

-S (Sum)

Starts top with the last remembered 'S' state reversed. When 'Cumulative mode' is On, each process is listed with the cpu time that it and its dead children have used. See the 'S' interactive command for additional information regarding this mode.

Description of the fields

a: PID -- Process Id

The task's unique process ID, which periodically wraps, though never restarting at zero.

b: PPID -- Parent Process Pid

The process ID of a task's parent.

c: RUSER -- Real User Name

The real user name of the task's owner.

d: UID -- User Id

The effective user ID of the task's owner.

e: USER -- User Name

The effective user name of the task's owner.

f: GROUP -- Group Name

The effective group name of the task's owner.

g: TTY -- Controlling Tty

The name of the controlling terminal. This is usually the device (serial port, pty, etc.) from which the process was started, and which it uses for input or output. However, a task need not be associated with a terminal, in which case you'll see '?' displayed.

h: PR -- Priority

The priority of the task.

i: NI -- Nice value

The nice value of the task. A negative nice value means higher priority, whereas a positive nice value means lower priority. Zero in this field simply means priority will not be adjusted in determining a task's dispatchability./dd>

j: P -- Last used CPU (SMP)

A number representing the last used processor. In a true SMP environment this will likely change frequently since the kernel intentionally uses weak affinity. Also, the very act of running top may break this weak affinity and cause more processes to change CPUs more often (because of the extra demand for cpu time).

k: %CPU -- CPU usage

The task's share of the elapsed CPU time since the last screen update, expressed as a percentage of total CPU time. In a true SMP environment, if 'Irix mode' is Off, top will operate in 'Solaris mode' where a task's cpu usage will be divided by the total number of CPUs. You toggle 'Irix/Solaris' modes with the 'I' interactive command.

l: TIME -- CPU Time

Total CPU time the task has used since it started. When 'Cumulative mode' is On, each process is listed with the cpu time that it and its dead children has used. You toggle 'Cumulative mode' with 'S', which is a command-line option and an interactive command. See the 'S' interactive command for additional information regarding this mode.

m: TIME+ -- CPU Time, hundredths

The same as 'TIME', but reflecting more granularity through hundredths of a second.

n: %MEM -- Memory usage (RES)

A task's currently used share of available physical memory.

o: VIRT -- Virtual Image (kb)

The total amount of virtual memory used by the task. It includes all code, data and shared libraries plus pages that have been swapped out.

VIRT = SWAP + RES.

p: SWAP -- Swapped size (kb)

The swapped out portion of a task's total virtual memory image.

q: RES -- Resident size (kb)

The non-swapped physical memory a task has used.

RES = CODE + DATA.

r: CODE -- Code size (kb)

The amount of physical memory devoted to executable code, also known as the 'text resident set' size or TRS.

s: DATA -- Data+Stack size (kb)

The amount of physical memory devoted to other than executable code, also known as the 'data resident set' size or DRS.

t: SHR -- Shared Mem size (kb)

The amount of shared memory used by a task. It simply reflects memory that could be potentially shared with other processes.

u: nFLT -- Page Fault count

The number of major page faults that have occurred for a task. A page fault occurs when a process attempts to read from or write to a virtual page that is not currently present in its address space. A major page fault is when disk access is involved in making that page available.

v: nDRT -- Dirty Pages count

The number of pages that have been modified since they were last written to disk. Dirty pages must be written to disk before the corresponding physical memory location can be used for some other virtual page.

w: S -- Process Status

The status of the task which can be one of:
'D' = uninterruptible sleep
'R' = running
'S' = sleeping
'T' = traced or stopped
'Z' = zombie

Tasks shown as running should be more properly thought of as 'ready to run' -- their task_struct is simply represented on the Linux run-queue. Even without a true SMP machine, you may see numerous tasks in this state depending on top's delay interval and nice value.

x: Command -- Command line or Program name

Display the command line used to start a task or the name of the associated program. You toggle between command line and name with 'c', which is both a command-line option and an interactive command.

When you've chosen to display command lines, processes without a command line (like kernel threads) will be shown with only the program name in parentheses, as in this example:

( mdrecoveryd )

Either form of display is subject to potential truncation if it's too long to fit in this field's current width. That width depends upon other fields selected, their order and the current screen width.

Note: The 'Command' field/column is unique, in that it is not fixed-width. When displayed, this column will be allocated all remaining screen width (up to the maximum 512 characters) to provide for the potential growth of program names into command lines.

y: WCHAN -- Sleeping in Function

Depending on the availability of the kernel link map ('System.map'), this field will show the name or the address of the kernel function in which the task is currently sleeping. Running tasks will display a dash ('-') in this column.

Note: By displaying this field, top's own working set will be
increased by over 700Kb. Your only means of reducing that overhead
will be to stop and restart top.

z: Flags -- Task Flags

This column represents the task's current scheduling flags which are expressed in hexadecimal notation and with zeros suppressed. These flags are officially documented in . Less formal documentation can also be found on the 'Fields select' and 'Order fields' screens.

Interactive commands

While top is running you may issue some options that will interact immediately with top these options are:

h

Help, displays a summary of command that will modify the behavior of top

k

Kills a process, you will be able to kill only your own processes, unless you are running top as root

n

Once this command is entered top will ask you how many lines you want on your screen, if you enter 0 top will display as much as it can

q

Exits top

r

Change the priority of a process, as well as with k you will only be able to act on your own processes unless you are root

W

Writes the current configuration to your personal configuration file, which is $HOME/.toprc

Inodes Linux /Unix

=> File type (executable, block special etc)
=> Permissions (read, write etc)
=> Owner
=> Group
=> File Size
=> File access, change and modification time (remember UNIX or Linux never stores file creation time, this is favorite question asked in UNIX/Linux sys admin job interview)
=> File deletion time
=> Number of links (soft/hard)
=> Extended attribute such as append only or no one can delete file including root user (immutability)
=> Access Control List (ACLs)

Each inode is identified by a unique inode number within the file system. Inode is also know as index number.

How do I see file inode number?

[root@rajat Desktop]# stat Amazon\ Web\ Services.pdf 

  File: `Amazon Web Services.pdf'

  Size: 1968423   Blocks: 3848       IO Block: 4096   regular file

Device: 803h/2051d Inode: 262327      Links: 1

Access: (0644/-rw-r--r--)  Uid: (  500/   rajat)   Gid: (  500/   rajat)

Access: 2011-03-25 10:22:30.192428487 +0530

Modify: 2010-06-01 00:34:44.000000000 +0530

Change: 2011-03-21 23:20:08.933990061 +0530

[root@rajat Desktop]#ls -i Amazon\ Web\ Services.pdf 

262327 Amazon Web Services.pdf 

Zombie Process Linux

A process can be sleeping in kernel code. Usually that's because of faulty hardware or a badly written driver- or maybe a little of both. A device that isn't set to the interrupt the driver thinks it is can cause this, for example- the driver is waiting for something its never going to get. The process doesn't ignore your signal- it just never gets it.
A zombie process doesn't react to signals because it's not really a process at all- it's just what's left over after it died. What's supposed to happen is that its parent process was to issue a "wait()" to collect the information about its exit. If the parent doesn't (programming error or just bad programming), you get a zombie. The zombie will go away if its parent dies- it will be "adopted" by init which will do the wait()- so if you see one hanging about, check its parent; if it is init, it will be gone soon, if not the only recourse is to kill the parent..which you may or may not want to do.
* Finally, a process that is being traced (by a debugger, for example) won't react to the KILL either.

We can find out zombie process by :-
Use top or ps command:

# top
OR
# ps aux | awk '{ print $8 " " $2 }' | grep -w Z
#ps -el | grep Z

How do I kill zombie process?
You cannot kill zombies, as they are already dead. But if you have too many zombies then kill parent process or restart service.

You can kill zombie process using PID obtained from any one of the above command. For example kill zombie proces having PID 4104:
# kill -9 4104
*Please note that kill -9 does not guarantee to kill a zombie process

How do I automate zombie process killing?
Write a script and schedule as a cron job.

 `ps jauxww | grep Z | grep -v PID | awk ‘{print $3}’`; do for every in `ps auxw | grep $each | grep cron | awk ‘{print $2}’`; do kill -9 $every; done; done