Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Linux+ Certification Bible.pdf
Скачиваний:
47
Добавлен:
15.03.2015
Размер:
3.78 Mб
Скачать

Chapter 12 Linux Disk and System Management

391

To create an entry for cron, use the crontab -e command. This command brings you into the vi editor program, where you can write your cron entry in the format as listed in the preceding example. After you finish, save your file and exit vi.

User crontabs are saved in /var/spool/cron/ with a directory for each user that stores all the user’s cron jobs.

To see your cron jobs, use the crontab -l command. To delete your cron jobs, use the crontab -r command.

Remember that the at command can only run a job at one particular time. Cron can schedule recurring tasks.

Core Dumps

5.3 Identify core dumps and remove or forward as appropriate

Inevitably, one of your system’s applications or even a core system process will malfunction — causing a core dump. A core dump is a file that is created by an application or service that has crashed. The most serious type of system crash is a kernel crash, often called a kernel “panic.” The information recorded in a core file is a snapshot of what was in memory at the time of the crash, and contains information important for debugging the application. A programmer can use this information to find out what caused the application to crash, and to modify the application to prevent future crashes. A program may crash for several reasons, such as lack of memory or disk space, invalid input, a hardware failure, or even a program bug.

This file, usually called the “core,” is dumped into the current working directory. If you are not using this file at all to debug an application, you should delete it. Depending on the application, a core file may be extremely large, and can quickly use up valuable disk space. You can limit the size of a core file, or even turn off core dumping by using the ulimit command. I recommend against disabling core dumps because they contain very important debugging information that is needed

to fix the application. The ulimit command sets various parameters for user environment settings. The core file size is specified in blocks. By default, the size is usually set to 1,000,000 blocks. You can turn off core dumps by issuing the following command:

ulimit -c 0

This command sets the core dump file size to zero, effectively disabling it. To see that the command worked, use the following command, which will show all of your user limit settings:

ulimit -a

392 Part V Maintaining the Linux System

Analyzing core dumps

Just by looking at the memory dump, the cause of the crash may not be immediately apparent. The information is very technical and confusing, showing actual memory addresses and program routines. Thankfully, many types of debugging tools are available that can help you analyze a core dump file and allow you to more accurately debug the problem. However, you may benefit more by forwarding the core dump to the programmer of the application, so that they can fix the bugs in their program.

GNU Debugger

By using the gdb (GNU Debugger) program, you can analyze your program’s core dump files and also debug the application while it is actually running. You can invoke the program on a core file by issuing the following command:

gdb -c core

This command launches the gdb program on a core file called “core,” and displays the name of the program that created the core file and the signal on which the program terminated.

The following is an example of the output of the gdb command on a core file from the Apache Web server:

Core was generated by `httpd’.

Program terminated with signal 11, Segmentation fault. gdb> bt

#0 0x5c8b1674 in ?? ()

#1 0x4018df03 in zend_hash_add_or_update (ht=0x143280, arKey=0x4018aa3d “stdclass”, nKeyLength=9, pData=0x40253000, nDataSize=128, pDest=0x0, flag=2) at zend_hash.c:284

#2 0x4018ab45 in register_standard_class () at zend.c:243

#3 0x4018ad06 in zend_startup (utility_functions=0xefbfd770, extensions=0x0, start_builtin_functions=1) at zend.c:371

#4 0x401a548e in php_module_startup (sf=0xc8000) at main.c:807

#5 0x401a26dc in php_apache_startup (sapi_module=0xc8000) at mod_php4.c:270 #6 0x401a313c in php_init_handler (s=0xf6034, p=0xf600c) at mod_php4.c:694 #7 0x3d5d9 in ap_init_modules ()

#8 0x4b2b9 in main ()

The average user or system administrator may never need to use this information, but it is very valuable to programmers. The following is a list of commands that can be used in gdb.

quit: Terminate gdb

where: Show the call stack where execution has been halted

p: Print the value of a variable or expression