Kernel panic - not syncing: Attempted to kill init!
When the kernel gets into a situation where it does not know how to proceed (most often during booting, but at other times), it issues a kernel panic by calling the panic(msg) routine defined in kernel/panic.c. (Good name, huh?) This is a call from which No One Ever Returns.
The panic() routine adds text to the front of the message, telling you more about what the system was actually doing when the panic occurred ... basically how big and bad the trail of debris in the filesystem is likely to be. This is where the "not syncing" part comes from, and when you see that, it's good. (panic() doessinc() system-call to push all buffered data out to the hard-disks before it goes down.)
The second part of the message is what was provided by the original call to panic(). For example, we find panic("Tried to kill init!") it tries to issue a kernel/exit.c.
So, what does this actually mean? Well, in this case it really doesn't mean that someone tried to kill the magical init process (process #1...), but simply that it tried to die. ( This process is not allowed to die or to be killed. )
When you see this message, it's almost always at boot-time, and the real messages ... the cause of the actual failure ... will be found in the startup messages immediately preceding this one. This is often the case with kernel-panics. init encountered something "really bad," and it didn't know what to do, so it died, so the kernel died too.
BTW, the kernel-panic code is rather cute. It can blink lights and beep the system-speaker in Morse code. It can reboot the system automagically. Obviously the people who wrote this stuff encountered it a lot...
In diagnosing, or at least understanding, kernel-panics, I find it extremely helpful to have on-hand a copy of the Linux source-code, which is usually stored someplace like /usr/src/linux-2.x. You can use the grep utility to locate the actual code which caused the panic to occur.
Things to know about linux
What is the minimum number of partitions you need to install Linux?
What command can you use to review boot messages?
only need 2 partitions to install Linux one is the root partition / and other is the swap partition ,you can install linux without creating /boot ,it will automatically created under /
dmesg will show you the logged messages at boot time .most information is about detected hardware at boot time
what is stored at /lib/modules ? It contains all the kernel modules that needed to be loaded
into kernel (booting etc). there will some .map, .dep
(dependency files) files present.
When the kernel needs a feature that is not resident in the
kernel, the kernel module daemon kmod[1] execs modprobe to
load the module in.
You can see what modules are already loaded into the kernel
by running lsmod, which gets its information by reading the
file /proc/modules
How to Load a Linux kernel module automatically at boot time
When the kernel needs a feature that is not resident in the kernel, the kernel module
daemon kmod[1] execs modprobe to load the module in.
modprobe first searches a files called File /etc/modules.conf is configuration file for loading kernel modules.
what is stored in /proc ?
what is significance of /proc in linux ?
Mainly hardware related information such as CPU
information, Memory (RAM) information stored under /proc
directory
example:
# cat /proc/cpuinfo (show the information of CPU of that
particular hardware)
# cat /proc/meminfo (show the information of Memory i.e.
RAM of that particular hardware)
why the kernel panic error was appering?
Kernel panic error occurs when a Linux OS files system goes curroupt or it cannot read the file system
postfix mail flow
Receiving Mail
When a message enters the Postfix mail system, the first stop is the incoming queue. The figure below shows the main components that are involved with new mail.
Mail is posted locally. The Postfix sendmail program invokes the privileged postdrop program which deposits the message into the maildrop directory, where the message is picked up by the pickup daemon. This daemon does some sanity checks, in order to protect the rest of the Postfix system.
Mail comes in via the network. The Postfix SMTP server receives the message and does some sanity checks, in order to protect the rest of the Postfix system.
Mail is generated internally by the Postfix system itself, in order to return undeliverable mail to the sender. The bounce or defer daemon brings the bad news.
Mail is forwarded by the local delivery agent, either via an entry in the system-wide alias database, or via an entry in a per-user .forward file. This is indicated with the unlabeled arrow.
Mail is generated internally by the Postfix system itself, in order to notify the postmaster of a problem (this path is also indicated with the unlabeled arrow).The Postfix system can be configured to notify the postmaster of SMTP protocol problems, UCE policy violations, and so on.
The cleanup daemon implements the final processing stage for new mail. It adds missing From: and other message headers, arranges for address rewriting to the standard user@fully.qualified.domain form, and optionally extracts recipient addresses from message headers. The cleanup daemon inserts the result as a single queue file into the incoming queue, and notifies the queue manager of the arrival of new mail. The cleanup daemon can be configured to transform addresses on the basis of canonical and virtua table lookups.
On request by the cleanup daemon, the trivial-rewrite daemon rewrites addresses to the standard user@fully.qualified.domain form.
Subscribe to:
Posts (Atom)