Don't use any log storage and forward to console directly, this make console output more useful, and also save more memory. On a fresh installed Fedora 30 it saved ~5M of memory, and the amount of log being printed to console is still acceptable.
Signed-off-by: Kairui Song kasong@redhat.com --- dracut-module-setup.sh | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 5222040..27b9f02 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -822,4 +822,11 @@ install() { echo "[Manager]" > ${initdir}/etc/systemd/system.conf.d/kdump.conf echo "DefaultTimeoutStartSec=300s" >> ${initdir}/etc/systemd/system.conf.d/kdump.conf fi + + # Forward logs to console directly, this avoids unneccessary memory + # consumption and make console output more useful + mkdir -p ${initdir}/etc/systemd/journald.conf.d + echo "[Journal]" > ${initdir}/etc/systemd/journald.conf.d/kdump.conf + echo "Storage=none" >> ${initdir}/etc/systemd/journald.conf.d/kdump.conf + echo "ForwardToConsole=yes" >> ${initdir}/etc/systemd/journald.conf.d/kdump.conf }
Hi Kairui, On 06/28/19 at 11:11pm, Kairui Song wrote:
Don't use any log storage and forward to console directly, this make console output more useful, and also save more memory. On a fresh installed Fedora 30 it saved ~5M of memory, and the amount of log being printed to console is still acceptable.
looks nice, only concern is if we could get lots of systemd debug msgs so that it floods the console output, otherwise it is a good idea.
could you double check that?
Signed-off-by: Kairui Song kasong@redhat.com
dracut-module-setup.sh | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 5222040..27b9f02 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -822,4 +822,11 @@ install() { echo "[Manager]" > ${initdir}/etc/systemd/system.conf.d/kdump.conf echo "DefaultTimeoutStartSec=300s" >> ${initdir}/etc/systemd/system.conf.d/kdump.conf fi
- # Forward logs to console directly, this avoids unneccessary memory
- # consumption and make console output more useful
- mkdir -p ${initdir}/etc/systemd/journald.conf.d
- echo "[Journal]" > ${initdir}/etc/systemd/journald.conf.d/kdump.conf
- echo "Storage=none" >> ${initdir}/etc/systemd/journald.conf.d/kdump.conf
- echo "ForwardToConsole=yes" >> ${initdir}/etc/systemd/journald.conf.d/kdump.conf
}
2.21.0 _______________________________________________ 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
On Tue, Jul 2, 2019 at 10:13 AM Dave Young dyoung@redhat.com wrote:
Hi Kairui, On 06/28/19 at 11:11pm, Kairui Song wrote:
Don't use any log storage and forward to console directly, this make console output more useful, and also save more memory. On a fresh installed Fedora 30 it saved ~5M of memory, and the amount of log being printed to console is still acceptable.
looks nice, only concern is if we could get lots of systemd debug msgs so that it floods the console output, otherwise it is a good idea.
could you double check that?
Yes, it will increase the console output line number for sure, but the content won't increase much (~700 lines without the patch, to ~800 lines of log with the patch in my VM test, similiar result with nfs/local dump), and the system log is printed to the console gradually as boot progresses, so it should be fine.
-- Best Regards, Kairui Song
On 07/08/19 at 12:59am, Kairui Song wrote:
On Tue, Jul 2, 2019 at 10:13 AM Dave Young dyoung@redhat.com wrote:
Hi Kairui, On 06/28/19 at 11:11pm, Kairui Song wrote:
Don't use any log storage and forward to console directly, this make console output more useful, and also save more memory. On a fresh installed Fedora 30 it saved ~5M of memory, and the amount of log being printed to console is still acceptable.
looks nice, only concern is if we could get lots of systemd debug msgs so that it floods the console output, otherwise it is a good idea.
could you double check that?
Yes, it will increase the console output line number for sure, but the content won't increase much (~700 lines without the patch, to ~800 lines of log with the patch in my VM test, similiar result with nfs/local dump), and the system log is printed to the console gradually as boot progresses, so it should be fine.
Ok, then looks good:
Acked-by: Dave Young dyoung@redhat.com
Thanks Dave