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 | 92 +++++++++++++++++++++++++++++-------------- 1 file changed, 62 insertions(+), 30 deletions(-)
diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt index 5f57a8428e4f..3ec2f1da82dd 100644 --- a/kexec-kdump-howto.txt +++ b/kexec-kdump-howto.txt @@ -888,35 +888,67 @@ 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) - - 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 + You can configure the kdump log level in the /etc/sysconfig/kdump. + For example: + + kdump_sysloglvl=3 + kdump_stdloglvl=3
The above configurations indicate that kdump messages will be printed to the - console and journald if the journald service is enabled. + console and journald if the journald service is enabled, and the log level is + set to 3(info). This is also the current default log level. + + Logging levels: error(1),warn(2),info(3),debug(4) + + 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. + + At present, the logger works in both the first kernel(kdump service debugging) + and the second kernel. + + 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 + + If you want to get the debugging information of building kdump initramfs, you + can enable the '--debug' option for the dracut_args in the /etc/kdump.conf, and + then rebuild the kdump initramfs as below: + + # systemctl restart kdump.service + + That will rebuild the kdump initramfs and gerenate some logs to journald, you + can find the dracut logs with the journalctl command. + + In the second kernel, kdump will automatically 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. + + In addition, you can also add the 'rd.memdebug=X' option to the KDUMP_COMMANDLINE_APPEND + in the /etc/sysconfig/kdump in order to output the additional information about + kernel module memory consumption during loading. + + For more details, please refer to the /etc/sysconfig/kdump, or the man page of + dracut.cmdline and kdump.conf.
On 11/05/20 at 02:25pm, Lianbo Jiang wrote:
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 | 92 +++++++++++++++++++++++++++++-------------- 1 file changed, 62 insertions(+), 30 deletions(-)
diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt index 5f57a8428e4f..3ec2f1da82dd 100644 --- a/kexec-kdump-howto.txt +++ b/kexec-kdump-howto.txt @@ -888,35 +888,67 @@ 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)
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
You can configure the kdump log level in the /etc/sysconfig/kdump.
For example:
kdump_sysloglvl=3
kdump_stdloglvl=3
The above configurations indicate that kdump messages will be printed to the
- console and journald if the journald service is enabled.
- console and journald if the journald service is enabled, and the log level is
- set to 3(info). This is also the current default log level.
- Logging levels: error(1),warn(2),info(3),debug(4)
- The ERROR level designates error events that might still allow the application
- to continue running.
Error events includes those which might still allow the application to ocntinue running, and those which could corrupt the running application, right?
- 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.
- At present, the logger works in both the first kernel(kdump service debugging)
- and the second kernel.
- 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
- If you want to get the debugging information of building kdump initramfs, you
- can enable the '--debug' option for the dracut_args in the /etc/kdump.conf, and
- then rebuild the kdump initramfs as below:
- # systemctl restart kdump.service
- That will rebuild the kdump initramfs and gerenate some logs to journald, you
- can find the dracut logs with the journalctl command.
- In the second kernel, kdump will automatically 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.
- In addition, you can also add the 'rd.memdebug=X' option to the KDUMP_COMMANDLINE_APPEND
- in the /etc/sysconfig/kdump in order to output the additional information about
- kernel module memory consumption during loading.
- For more details, please refer to the /etc/sysconfig/kdump, or the man page of
- dracut.cmdline and kdump.conf.
-- 2.17.1 _______________________________________________ kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org
Hi, bhe
Thanks for the comment.
在 2020年11月12日 12:30, Baoquan He 写道:
On 11/05/20 at 02:25pm, Lianbo Jiang wrote:
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 | 92 +++++++++++++++++++++++++++++-------------- 1 file changed, 62 insertions(+), 30 deletions(-)
diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt index 5f57a8428e4f..3ec2f1da82dd 100644 --- a/kexec-kdump-howto.txt +++ b/kexec-kdump-howto.txt @@ -888,35 +888,67 @@ 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)
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
You can configure the kdump log level in the /etc/sysconfig/kdump.
For example:
kdump_sysloglvl=3
kdump_stdloglvl=3
The above configurations indicate that kdump messages will be printed to the
- console and journald if the journald service is enabled.
- console and journald if the journald service is enabled, and the log level is
- set to 3(info). This is also the current default log level.
- Logging levels: error(1),warn(2),info(3),debug(4)
- The ERROR level designates error events that might still allow the application
- to continue running.
Error events includes those which might still allow the application to ocntinue running, and those which could corrupt the running application, right? Yes. The ERROR events(log level) only provides a way to print the error event
information, it won't break the application behavior, that should be done by the application, not the log level.
Thanks. Lianbo
- 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.
- At present, the logger works in both the first kernel(kdump service debugging)
- and the second kernel.
- 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
- If you want to get the debugging information of building kdump initramfs, you
- can enable the '--debug' option for the dracut_args in the /etc/kdump.conf, and
- then rebuild the kdump initramfs as below:
- # systemctl restart kdump.service
- That will rebuild the kdump initramfs and gerenate some logs to journald, you
- can find the dracut logs with the journalctl command.
- In the second kernel, kdump will automatically 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.
- In addition, you can also add the 'rd.memdebug=X' option to the KDUMP_COMMANDLINE_APPEND
- in the /etc/sysconfig/kdump in order to output the additional information about
- kernel module memory consumption during loading.
- For more details, please refer to the /etc/sysconfig/kdump, or the man page of
- dracut.cmdline and kdump.conf.
-- 2.17.1 _______________________________________________ kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org
-
Baoquan He -
Lianbo Jiang -
lijiang