KLOGD
8
21 August, 1999
Version 1.4
Linux System Administration
This information is EXTREMELY IMPORTANT in determining what caused the internal error condition. The difficulty comes when a kernel developer attempts to analyze this information. The raw numeric information present in the protection fault printout is of very little use to the developers. This is due to the fact that kernels are not identical and the addresses of variable locations or functions will not be the same in all kernels. In order to correctly diagnose the cause of failure a kernel developer needs to know what specific kernel functions or variable locations were involved in the error. As part of the kernel compilation process a listing is created which specified the address locations of important variables and function in the kernel being compiled. This listing is saved in a file called System.map in the top of the kernel directory source tree. Using this listing a kernel developer can determine exactly what the kernel was doing when the error condition occurred. The process of resolving the numeric addresses from the protection fault printout can be done manually or by using the ksymoops program which is included in the kernel sources. As a convenience klogd will attempt to resolve kernel numeric addresses to their symbolic forms if a kernel symbol table is available at execution time. If you require the original address of the symbol, use the -2 switch to preserve the numeric address. A symbol table may be specified by using the -k /boot/System.map /System.map /usr/src/linux/System.map Version information is supplied in the system maps as of kernel 1.3.43. This version information is used to direct an intelligent search of the list of symbol tables. This feature is useful since it provides support for both production and experimental kernels. For example a production kernel may have its map file stored in /boot/System.map. If an experimental or test kernel is compiled with the sources in the 'standard' location of /usr/src/linux the system map will be found in /usr/src/linux/System.map. When klogd starts under the experimental kernel the map in /boot/System.map will be bypassed in favor of the map in /usr/src/linux/System.map. Modern kernels as of 1.3.43 properly format important kernel addresses so that they will be recognized and translated by klogd. Earlier kernels require a source code patch be applied to the kernel sources. This patch is supplied with the sysklogd sources. The process of analyzing kernel protections faults works very well with a static kernel. Additional difficulties are encountered when attempting to diagnose errors which occur in loadable kernel modules. Loadable kernel modules are used to implement kernel functionality in a form which can be loaded or unloaded at will. The use of loadable modules is useful from a debugging standpoint and can also be useful in decreasing the amount of memory required by a kernel. The difficulty with diagnosing errors in loadable modules is due to the dynamic nature of the kernel modules. When a module is loaded the kernel will allocate memory to hold the module, when the module is unloaded this memory will be returned back to the kernel. This dynamic memory allocation makes it impossible to produce a map file which details the addresses of the variable and functions in a kernel loadable module. Without this location map it is not possible for a kernel developer to determine what went wrong if a protection fault involves a kernel module. klogd When a protection fault occurs an attempt will be made to resolve kernel addresses from the static symbol table. If this fails the symbols from the currently loaded modules are examined in an attempt to resolve the addresses. At the very minimum this allows klogd to indicate which loadable module was responsible for generating the protection fault. Additional information may be available if the module developer chose to export symbol information from the module. Proper and accurate resolution of addresses in kernel modules requires that klogd be informed whenever the kernel module status changes. The -i and -I switches can be used to signal the currently executing daemon that symbol information be reloaded. Of most importance to proper resolution of module symbols is the -i switch. Each time a kernel module is loaded or removed from the kernel the following command should be executed: klogd -i The -p switch can also be used to insure that module symbol information is up to date. This switch instructs klogd to reload the module symbol information whenever a protection fault is detected. Caution should be used before invoking the program in 'paranoid' mode. The stability of the kernel and the operating environment is always under question when a protection fault occurs. Since the klogd daemon must execute system calls in order to read the module symbol information there is the possibility that the system may be too unstable to capture useful information. A much better policy is to insure that klogd is updated whenever a module is loaded or unloaded. Having uptodate symbol information loaded increases the probability of properly resolving a protection fault if it should occur. Included in the sysklogd source distribution is a patch to the modules-2.0.0 package which allows the insmod, rmmod and modprobe utilities to automatically signal klogd whenever a module is inserted or removed from the kernel. Using this patch will insure that the symbol information maintained in klogd is always consistent with the current kernel state.
The SIGTSTP " and " SIGCONT signals are used to start and stop kernel logging. Upon receipt of a SIGTSTP signal the daemon will close its log sources and spin in an idle loop. Subsequent receipt of a SIGCONT signal will cause the daemon to go through its initialization sequence and re-choose an input source. Using SIGSTOP " and " SIGCONT in combination the kernel log input can be re-chosen without stopping and restarting the daemon. For example if the /proc
|
||||||||||
