Penguin
Annotated edit history of klogd(8) version 1, including all changes. View license author blame.
Rev Author # Line
1 perry 1 KLOGD
2 !!!KLOGD
3 NAME
4 SYNOPSIS
5 DESCRIPTION
6 OPTIONS
7 OVERVIEW
8 KERNEL ADDRESS RESOLUTION
9 SIGNAL HANDLING
10 FILES
11 BUGS
12 AUTHOR
13 ----
14 !!NAME
15
16
17 klogd - Kernel Log Daemon
18 !!SYNOPSIS
19
20
21 __klogd__ [[ __-c__ ''n'' ] [[ __-d__ ] [[
22 __-f__ ''fname'' ] [[ __-iI__ ] [[ __-n__ ] [[
23 __-o__ ] [[ __-p__ ] [[ __-s__ ] [[ __-k__
24 ''fname'' ] [[ __-v__ ] [[ __-x__ ] [[ __-2__
25 ]
26 !!DESCRIPTION
27
28
29 __klogd__ is a system daemon which intercepts and logs
30 Linux kernel messages.
31 !!OPTIONS
32
33
34 __-c__ ''n''
35
36
37 Sets the default log level of console messages to
38 ''n''.
39
40
41 __-d__
42
43
44 Enable debugging mode. This will generate __LOTS__ of
45 output to stderr.
46
47
48 __-f__ ''file''
49
50
51 Log messages to the specified filename rather than to the
52 syslog facility.
53
54
55 __-i -I__
56
57
58 Signal the currently executing klogd daemon. Both of these
59 switches control the loading/reloading of symbol
60 information. The -i switch signals the daemon to reload the
61 kernel module symbols. The -I switch signals for a reload of
62 both the static kernel symbols and the kernel module
63 symbols.
64
65
66 __-n__
67
68
69 Avoid auto-backgrounding. This is needed especially if the
70 __klogd__ is started and controlled by
71 init(8).
72
73
74 __-o__
75
76
77 Execute in 'one-shot' mode. This causes __klogd__ to read
78 and log all the messages that are found in the kernel
79 message buffers. After a single read and log cycle the
80 daemon exits.
81
82
83 __-p__
84
85
86 Enable paranoia. This option controls when klogd loads
87 kernel module symbol information. Setting this switch causes
88 klogd to load the kernel module symbol information whenever
89 an Oops string is detected in the kernel message
90 stream.
91
92
93 __-s__
94
95
96 Force __klogd__ to use the system call interface to the
97 kernel message buffers.
98
99
100 __-k__ ''file''
101
102
103 Use the specified file as the source of kernel symbol
104 information.
105
106
107 __-v__
108
109
110 Print version and exit.
111
112
113 __-x__
114
115
116 Omits EIP translation and therefore doesn't read the
117 System.map file.
118
119
120 __-2__
121
122
123 When symbols are expanded, print the line twice. Once with
124 addresses converted to symbols, once with the raw text. This
125 allows external programs such as ksymoops do their own
126 processing on the original data.
127 !!OVERVIEW
128
129
130 The functionality of klogd has been typically incorporated
131 into other versions of syslogd but this seems to be a poor
132 place for it. In the modern Linux kernel a number of kernel
133 messaging issues such as sourcing, prioritization and
134 resolution of kernel addresses must be addressed.
135 Incorporating kernel logging into a separate process offers
136 a cleaner separation of services.
137
138
139 In Linux there are two potential sources of kernel log
140 information: the ''/proc'' file system and the syscall
141 (sys_syslog) interface, although ultimately they are one and
142 the same. Klogd is designed to choose whichever source of
143 information is the most appropriate. It does this by first
144 checking for the presence of a mounted ''/proc'' file
145 system. If this is found the ''/proc/kmsg'' file is used
146 as the source of kernel log information. If the proc file
147 system is not mounted __klogd__ uses a system call to
148 obtain kernel messages. The command line switch (__-s__)
149 can be used to force klogd to use the system call interface
150 as its messaging source.
151
152
153 If kernel messages are directed through the __syslogd__
154 daemon the __klogd__ daemon, as of version 1.1, has the
155 ability to properly prioritize kernel messages.
156 Prioritization of the kernel messages was added to it at
157 approximately version 0.99pl13 of the kernel. The raw kernel
158 messages are of the form:
159
160
161
162
163 The priority of the kernel message is encoded as a single
164 numeric digit enclosed inside the
165 -f__) is used the prioritization sequence is
166 left pre-pended to the kernel message.
167
168
169 The __klogd__ daemon also allows the ability to alter the
170 presentation of kernel messages to the system console.
171 Consequent with the prioritization of kernel messages was
172 the inclusion of default messaging levels for the kernel. In
173 a stock kernel the the default console log level is set to
174 7. Any messages with a priority level numerically lower than
175 7 (higher priority) appear on the console.
176
177
178 Messages of priority level 7 are considered to be 'debug'
179 messages and will thus not appear on the console. Many
180 administrators, particularly in a multi-user environment,
181 prefer that all kernel messages be handled by klogd and
182 either directed to a file or to the syslogd daemon. This
183 prevents 'nuisance' messages such as line printer out of
184 paper or disk change detected from cluttering the
185 console.
186
187
188 When __-c__ is given on the commandline the __klogd__
189 daemon will execute a system call to inhibit all kernel
190 messages from being displayed on the console. Former
191 versions always issued this system call and defaulted to all
192 kernel messages except for panics. This is handled
193 differently nowardays so __klogd__ doesn't need to set
194 this value anymore. The argument given to the __-c__
195 switch specifies the priority level of messages which will
196 be directed to the console. Note that messages of a priority
197 value LOWER than the indicated number will be directed to
198 the console.
199
200
201 For example, to have the kernel display all messages with a
202 priority level of 3 (__KERN_ERR__) or more severe the
203 following command would be executed:
204
205
206 klogd -c 4
207
208
209 The definitions of the numeric values for kernel messages
210 are given in the file ''kernel.h'' which can be found in
211 the ''/usr/include/linux'' directory if the kernel
212 sources are installed. These values parallel the syslog
213 priority values which are defined in the file
214 ''syslog.h'' found in the ''/usr/include/sys''
215 sub-directory.
216
217
218 The klogd daemon can also be used in a 'one-shot' mode for
219 reading the kernel message buffers. One shot mode is
220 selected by specifying the __-o__ switch on the command
221 line. Output will be directed to either the syslogd daemon
222 or to an alternate file specified by the __-f__
223 switch.
224
225
226 For example, to read all the kernel messages after a system
227 boot and record them in a file called krnl.msg the following
228 command would be given.
229
230
231 klogd -o -f ./krnl.msg
232 !!KERNEL ADDRESS RESOLUTION
233
234
235 If the kernel detects an internal error condition a general
236 protection fault will be triggered. As part of the GPF
237 handling procedure the kernel prints out a status report
238 indicating the state of the processor at the time of the
239 fault. Included in this display are the contents of the
240 microprocessor's registers, the contents of the kernel stack
241 and a tracing of what functions were being executed at the
242 time of the fault.
243
244
245 This information is __EXTREMELY IMPORTANT__ in
246 determining what caused the internal error condition. The
247 difficulty comes when a kernel developer attempts to analyze
248 this information. The raw numeric information present in the
249 protection fault printout is of very little use to the
250 developers. This is due to the fact that kernels are not
251 identical and the addresses of variable locations or
252 functions will not be the same in all kernels. In order to
253 correctly diagnose the cause of failure a kernel developer
254 needs to know what specific kernel functions or variable
255 locations were involved in the error.
256
257
258 As part of the kernel compilation process a listing is
259 created which specified the address locations of important
260 variables and function in the kernel being compiled. This
261 listing is saved in a file called System.map in the top of
262 the kernel directory source tree. Using this listing a
263 kernel developer can determine exactly what the kernel was
264 doing when the error condition occurred.
265
266
267 The process of resolving the numeric addresses from the
268 protection fault printout can be done manually or by using
269 the __ksymoops__ program which is included in the kernel
270 sources.
271
272
273 As a convenience __klogd__ will attempt to resolve kernel
274 numeric addresses to their symbolic forms if a kernel symbol
275 table is available at execution time. If you require the
276 original address of the symbol, use the __-2__ switch to
277 preserve the numeric address. A symbol table may be
278 specified by using the __-k__ switch on the command line.
279 If a symbol file is not explicitly specified the following
280 filenames will be tried:
281
282
283 ''/boot/System.map
284 /System.map
285 /usr/src/linux/System.map
286 ''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.
287
288
289 For example a production kernel may have its map file stored
290 in /boot/System.map. If an experimental or test kernel is
291 compiled with the sources in the 'standard' location of
292 /usr/src/linux the system map will be found in
293 /usr/src/linux/System.map. When klogd starts under the
294 experimental kernel the map in /boot/System.map will be
295 bypassed in favor of the map in
296 /usr/src/linux/System.map.
297
298
299 Modern kernels as of 1.3.43 properly format important kernel
300 addresses so that they will be recognized and translated by
301 klogd. Earlier kernels require a source code patch be
302 applied to the kernel sources. This patch is supplied with
303 the sysklogd sources.
304
305
306 The process of analyzing kernel protections faults works
307 very well with a static kernel. Additional difficulties are
308 encountered when attempting to diagnose errors which occur
309 in loadable kernel modules. Loadable kernel modules are used
310 to implement kernel functionality in a form which can be
311 loaded or unloaded at will. The use of loadable modules is
312 useful from a debugging standpoint and can also be useful in
313 decreasing the amount of memory required by a
314 kernel.
315
316
317 The difficulty with diagnosing errors in loadable modules is
318 due to the dynamic nature of the kernel modules. When a
319 module is loaded the kernel will allocate memory to hold the
320 module, when the module is unloaded this memory will be
321 returned back to the kernel. This dynamic memory allocation
322 makes it impossible to produce a map file which details the
323 addresses of the variable and functions in a kernel loadable
324 module. Without this location map it is not possible for a
325 kernel developer to determine what went wrong if a
326 protection fault involves a kernel module.
327
328
329 __klogd__ has support for dealing with the problem of
330 diagnosing protection faults in kernel loadable modules. At
331 program start time or in response to a signal the daemon
332 will interrogate the kernel for a listing of all modules
333 loaded and the addresses in memory they are loaded at.
334 Individual modules can also register the locations of
335 important functions when the module is loaded. The addresses
336 of these exported symbols are also determined during this
337 interrogation process.
338
339
340 When a protection fault occurs an attempt will be made to
341 resolve kernel addresses from the static symbol table. If
342 this fails the symbols from the currently loaded modules are
343 examined in an attempt to resolve the addresses. At the very
344 minimum this allows klogd to indicate which loadable module
345 was responsible for generating the protection fault.
346 Additional information may be available if the module
347 developer chose to export symbol information from the
348 module.
349
350
351 Proper and accurate resolution of addresses in kernel
352 modules requires that __klogd__ be informed whenever the
353 kernel module status changes. The __-i__ and __-I__
354 switches can be used to signal the currently executing
355 daemon that symbol information be reloaded. Of most
356 importance to proper resolution of module symbols is the
357 __-i__ switch. Each time a kernel module is loaded or
358 removed from the kernel the following command should be
359 executed:
360
361
362 ''klogd -i
363 ''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.
364
365
366 Included in the sysklogd source distribution is a patch to
367 the modules-2.0.0 package which allows the __insmod,
368 rmmod__ and __modprobe__ utilities to automatically
369 signal __klogd__ whenever a module is inserted or removed
370 from the kernel. Using this patch will insure that the
371 symbol information maintained in klogd is always consistent
372 with the current kernel state.
373 !!SIGNAL HANDLING
374
375
376 The __klogd__ will respond to eight signals:
377 __SIGHUP__, __SIGINT__, __SIGKILL__,
378 __SIGTERM__, __SIGTSTP__, __SIGUSR1__,
379 __SIGUSR2__ and __SIGCONT__. The __SIGINT__,
380 __SIGKILL__, __SIGTERM__ and __SIGHUP__ signals
381 will cause the daemon to close its kernel log sources and
382 terminate gracefully.
383
384
385 The __SIGTSTP__ and __SIGCONT__ signals are used to
386 start and stop kernel logging. Upon receipt of a
387 __SIGTSTP__ signal the daemon will close its log sources
388 and spin in an idle loop. Subsequent receipt of a
389 __SIGCONT__ signal will cause the daemon to go through
390 its initialization sequence and re-choose an input source.
391 Using __SIGSTOP__ and __SIGCONT__ in combination the
392 kernel log input can be re-chosen without stopping and
393 restarting the daemon. For example if the ''/proc'' file
394 system is to be un-mounted the following command sequence
395 should be used:
396
397
398 # kill -TSTP pid
399
400
401 # umount /proc
402
403
404 # kill -CONT pid
405
406
407 Notations will be made in the system logs with
408 __LOG_INFO__ priority documenting the start/stop of
409 logging.
410
411
412 The __SIGUSR1__ and __SIGUSR2__ signals are used to
413 initiate loading/reloading of kernel symbol information.
414 Receipt of the __SIGUSR1__ signal will cause the kernel
415 module symbols to be reloaded. Signaling the daemon with
416 __SIGUSR2__ will cause both the static kernel symbols and
417 the kernel module symbols to be reloaded.
418
419
420 Provided that the System.map file is placed in an
421 appropriate location the signal of generally greatest
422 usefulness is the __SIGUSR1__ signal. This signal is
423 designed to be used to signal the daemon when kernel modules
424 are loaded/unloaded. Sending this signal to the daemon after
425 a kernel module state change will insure that proper
426 resolution of symbols will occur if a protection fault
427 occurs in the address space occupied by a kernel
428 module.
429 !!FILES
430
431
432 ''/proc/kmsg''
433
434
435 One Source for kernel messages __klogd__
436
437
438 ''/var/run/klogd.pid''
439
440
441 The file containing the process id of
442 __klogd__
443
444
445 ''/boot/System.map, /System.map,
446 /usr/src/linux/System.map''
447
448
449 Default locations for kernel system maps.
450 !!BUGS
451
452
453 Probably numerous. Well formed context diffs
454 appreciated.
455 !!AUTHOR
456
457
458 The __klogd__ was originally written by Steve Lord
459 (lord@cray.com), Greg Wettstein made major
460 improvements.
461
462
463 Dr. Greg Wettstein (greg@wind.enjellic.com)
464
465
466 Enjellic Systems Development
467
468
469 Oncology Research Divsion Computing Facility
470
471
472 Roger Maris Cancer Center
473
474
475 Fargo, ND 58122
476 ----
This page is a man page (or other imported legacy content). We are unable to automatically determine the license status of this page.