panic happens. Set it up when you install
panic happens. Set it up when you install the server. That way, you’ll get a backtrace automatically if it ever crashes. This might seem like a novel idea, and it certainly isn’t emphasized in the FreeBSD documentation, but it makes sense to be ready for disaster. If it never happens, well, you don’t have anything to complain about. If you get a panic, you’re ready and you’ll be able to present the FreeBSD folks with a complete debugging dump the second a problem appears. Prerequisites prepare for a kernel panic, you need to have the system source code installed. You’ll also need one (or more) swap partitions that is at least 1MB larger than your physical memory, and preferably twice as large as your RAM. If you have 512MB of RAM, for example, you need a swap partition that is 513MB or larger, with 1024MB being preferable. (On a server, you should certainly have multiple swap partitions on multiple drives!) If your swap partition isn’t large enough, you’ll have to either add another hard drive with an adequate swap partition, or reinstall. (While having a /var partition with at least that much disk space free is helpful, it isn’t necessary.) If you followed the installation suggestions in the beginning of the book, you’re all set. Crash Dump Process The kernel crash-capturing process works somewhat like this. If a properly configured system crashes, it will save a core dump of the system memory. You can’t save it to a file, because the crashed kernel doesn’t know about files; it only knows about partitions. The simplest place to write this dump is to the swap partition, and the dump is placed as close to the end of the swap partition as possible. Once the crashing system saves the core to swap, it reboots the computer. During the reboot, /etc/rc enables the swap partition. It then (probably) runs fsck on the crashed disks. It has to enable swapping before running fsck, because fsck might need to use swap space. Hopefully, you have enough swap space that fsck can get everything it needs without overwriting the dump file lurking in your swap partition. Once the system has a place where it can save a core dump, it checks the swap partition for a dump. Upon finding a core dump, savecore copies the dump from swap to the proper file, clears the dump from swap, and lets the reboot proceed. You now have a kernel core file, and can use that to get a backtrace. The Debugging Kernel The standard FreeBSD kernel install removes all the debugging information from the kernel before installing it, including symbols, which provide a map between the machine code and the source code. Such a map can be larger than the actual program, and nobody wants to run a kernel that’s three times larger than it has to be! However, we need this map, and other debugging information, to diagnose what went wrong in the crash. This map also includes a complete list of source-code line numbers, so the developer can learn exactly where a problem occurred. Without this information, the developer is stuck trying to map a kernel core to the source code by hand, which is somewhat like trying to assemble a million-piece puzzle without a picture, or even knowing that you have all the pieces. Overall, this is an ugly job. It’s even uglier when you consider that the developer who needs to do the work is a volunteer. That’s why your debugging kernel should include its symbols. To keep the symbols, add these lines to your kernel configuration: 454
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services