Let's remove some redundant descriptions in the usage documentation of the logger, and make it clear.
Signed-off-by: Lianbo Jiang lijiang@redhat.com --- kexec-kdump-howto.txt | 81 ++++++++++++++++++++++++++++--------------- 1 file changed, 53 insertions(+), 28 deletions(-)
diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt index 5f57a8428e4f..46ca99b994c0 100644 --- a/kexec-kdump-howto.txt +++ b/kexec-kdump-howto.txt @@ -888,35 +888,60 @@ Debugging Tips
- Using the logger to output kdump log messages
- Currently, kdump messages are printed with the 'echo' command or redirect - to console, and which does not support to output kdump messages according - to the log level. - - That is not convenient to debug kdump issues, we usually need to capture - additional debugging information via the modification of the options or the - scripts like kdumpctl, mkdumprd, etc. Because there is no complete debugging - messages, which could waste valuable time. - - To cope with this challenging, we introduce the logger to output the kdump - messages according to the log level, and provide a chance to save logs to - the journald if the journald service is available, and then dump all logs - to a file, otherwise dump the logs with the dmesg to a file. - - Logging is controlled by following global variables: - - @var kdump_stdloglvl - logging level to standard error (console output) - - @var kdump_sysloglvl - logging level to syslog (by logger command) - - @var kdump_kmsgloglvl - logging level to /dev/kmsg (only for boot-time) - If any of the variables is not set, this function set it to default: - - @var kdump_stdloglvl=4 (info) - - @var kdump_sysloglvl=4 (info) - - @var kdump_kmsgloglvl=0 (no logging) + You can configure the kdump log level in the /etc/sysconfig/kdump. + For example: + + kdump_sysloglvl=4 + kdump_stdloglvl=4 + + The above configurations indicate that kdump messages will be printed to the + console and journald if the journald service is enabled, and the log level is + set to 4(info). This is also the current default log level.
Logging levels: fatal(1),error(2),warn(3),info(4),debug(5),trace(6)
- We can easily configure the above variables in the /etc/sysconfig/kdump. For - example: - kdump_sysloglvl=5 - kdump_stdloglvl=5 + The FATAL level designates very severe error events that will presumably lead + the application to abort. Currently, the FATAL level is not used.
- The above configurations indicate that kdump messages will be printed to the - console and journald if the journald service is enabled. + The ERROR level designates error events that might still allow the application + to continue running. + + The WARN level designates potentially harmful situations. + + The INFO level designates informational messages that highlight the progress + of the application at coarse-grained level. + + The DEBUG level designates fine-grained informational events that are most + useful to debug an application. + + The TRACE level designates finer-grained informational events than the DEBUG. + Currently, the TRACE level is not used. + + At present, the logger works in both the first kernel(kdump service debugging) + and the second kernel. But the TRACE and FATAL level are not used(as mentioned + above), which are only kept here as a syslog conversion. + + In the first kernel, you can find the historical logs with the journalctl + command and check kdump service debugging information. In addition, the + 'kexec -d' debugging messages are also saved to /var/log/kdump.log in the + first kernel. For example: + + [root@ibm-z-109 ~]# ls -al /var/log/kdump.log + -rw-r--r--. 1 root root 63238 Oct 28 06:40 /var/log/kdump.log + + In the second kernel, put the kexec-dmesg.log to a same directory with the + vmcore, the log file includes the debugging messages like dmesg and journald + logs. For example: + + [root@ibm-z-109 ~]# ls -al /var/crash/127.0.0.1-2020-10-28-02:01:23/ + drwxr-xr-x. 2 root root 67 Oct 28 02:02 . + drwxr-xr-x. 6 root root 154 Oct 28 02:01 .. + -rw-r--r--. 1 root root 21164 Oct 28 02:01 kexec-dmesg.log + -rw-------. 1 root root 74238698 Oct 28 02:01 vmcore + -rw-r--r--. 1 root root 17532 Oct 28 02:01 vmcore-dmesg.txt + + If you want to get more debugging information in the second kernel, you can add + the 'rd.debug' option to the KDUMP_COMMANDLINE_APPEND in the /etc/sysconfig/kdump, + and then reload them in order to make the changes take effect. + + For more details, please refer to the /etc/sysconfig/kdump.
Hi,
Please ignore the v2, I will update it with v3 because of some code changes.
I will post v3 later. Thanks.
Lianbo
在 2020年11月02日 21:38, Lianbo Jiang 写道:
Let's remove some redundant descriptions in the usage documentation of the logger, and make it clear.
Signed-off-by: Lianbo Jiang lijiang@redhat.com
kexec-kdump-howto.txt | 81 ++++++++++++++++++++++++++++--------------- 1 file changed, 53 insertions(+), 28 deletions(-)
diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt index 5f57a8428e4f..46ca99b994c0 100644 --- a/kexec-kdump-howto.txt +++ b/kexec-kdump-howto.txt @@ -888,35 +888,60 @@ Debugging Tips
Using the logger to output kdump log messages
Currently, kdump messages are printed with the 'echo' command or redirect
to console, and which does not support to output kdump messages according
to the log level.
That is not convenient to debug kdump issues, we usually need to capture
additional debugging information via the modification of the options or the
scripts like kdumpctl, mkdumprd, etc. Because there is no complete debugging
messages, which could waste valuable time.
To cope with this challenging, we introduce the logger to output the kdump
messages according to the log level, and provide a chance to save logs to
the journald if the journald service is available, and then dump all logs
to a file, otherwise dump the logs with the dmesg to a file.
Logging is controlled by following global variables:
- @var kdump_stdloglvl - logging level to standard error (console output)
- @var kdump_sysloglvl - logging level to syslog (by logger command)
- @var kdump_kmsgloglvl - logging level to /dev/kmsg (only for boot-time)
If any of the variables is not set, this function set it to default:
- @var kdump_stdloglvl=4 (info)
- @var kdump_sysloglvl=4 (info)
- @var kdump_kmsgloglvl=0 (no logging)
You can configure the kdump log level in the /etc/sysconfig/kdump.
For example:
kdump_sysloglvl=4
kdump_stdloglvl=4
The above configurations indicate that kdump messages will be printed to the
console and journald if the journald service is enabled, and the log level is
set to 4(info). This is also the current default log level.
Logging levels: fatal(1),error(2),warn(3),info(4),debug(5),trace(6)
- We can easily configure the above variables in the /etc/sysconfig/kdump. For
- example:
- kdump_sysloglvl=5
- kdump_stdloglvl=5
- The FATAL level designates very severe error events that will presumably lead
- the application to abort. Currently, the FATAL level is not used.
- The above configurations indicate that kdump messages will be printed to the
- console and journald if the journald service is enabled.
- The ERROR level designates error events that might still allow the application
- to continue running.
- The WARN level designates potentially harmful situations.
- The INFO level designates informational messages that highlight the progress
- of the application at coarse-grained level.
- The DEBUG level designates fine-grained informational events that are most
- useful to debug an application.
- The TRACE level designates finer-grained informational events than the DEBUG.
- Currently, the TRACE level is not used.
- At present, the logger works in both the first kernel(kdump service debugging)
- and the second kernel. But the TRACE and FATAL level are not used(as mentioned
- above), which are only kept here as a syslog conversion.
- In the first kernel, you can find the historical logs with the journalctl
- command and check kdump service debugging information. In addition, the
- 'kexec -d' debugging messages are also saved to /var/log/kdump.log in the
- first kernel. For example:
- [root@ibm-z-109 ~]# ls -al /var/log/kdump.log
- -rw-r--r--. 1 root root 63238 Oct 28 06:40 /var/log/kdump.log
- In the second kernel, put the kexec-dmesg.log to a same directory with the
- vmcore, the log file includes the debugging messages like dmesg and journald
- logs. For example:
- [root@ibm-z-109 ~]# ls -al /var/crash/127.0.0.1-2020-10-28-02:01:23/
- drwxr-xr-x. 2 root root 67 Oct 28 02:02 .
- drwxr-xr-x. 6 root root 154 Oct 28 02:01 ..
- -rw-r--r--. 1 root root 21164 Oct 28 02:01 kexec-dmesg.log
- -rw-------. 1 root root 74238698 Oct 28 02:01 vmcore
- -rw-r--r--. 1 root root 17532 Oct 28 02:01 vmcore-dmesg.txt
- If you want to get more debugging information in the second kernel, you can add
- the 'rd.debug' option to the KDUMP_COMMANDLINE_APPEND in the /etc/sysconfig/kdump,
- and then reload them in order to make the changes take effect.
- For more details, please refer to the /etc/sysconfig/kdump.