Commit Graph

1097 Commits

Author SHA1 Message Date
Xunlei Pang
d5fe9022d0 kdumpctl: move is_fadump_capable() to kdump-lib.sh
Make is_fadump_capable() a library function, as we will need
it in mkdumprd.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-09-06 15:39:23 +08:00
Xunlei Pang
1bd757bc96 Revert "kdumpctl: use generated rd.lvm.lv=X"
This reverts commit cb38b32dfc.

We are going to add "--hostonly-cmdline" dracut argument in
the following patch.

With the help of "--hostonly-cmdline", dracut will generate
"rd.lvm.lv=X" for us, no need to implement here again.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-09-06 15:38:39 +08:00
Xunlei Pang
8250f23c10 Revert "mkdumprd: omit crypt when there is no crypt kdump target"
This reverts commit 54a5bcc4ee.

We are going to add "--no-hostonly-default-device" dracut argument
in the following patch.

With the help of "--no-hostonly-default-device", dracut only
adds the dump target as host devices, which naturally guarantees
only required dracut modules being selected.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-09-06 15:38:09 +08:00
Xunlei Pang
dcffd4759e Revert "mkdumprd: omit dracut modules in case of no dm target"
This reverts commit 821d1af080.

We are going to add "--no-hostonly-default-device" dracut argument
in the following patch.

With the help of "--no-hostonly-default-device", dracut only
adds the dump target as host devices, which naturally guarantees
only required dracut modules being selected.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-09-06 15:37:45 +08:00
Xunlei Pang
2c9128a971 Revert "mkdumprd: omit dracut modules in case of network dumping"
This reverts commit fb522e972c.

We are going to add "--no-hostonly-default-device" dracut argument
in the following patch.

With the help of "--no-hostonly-default-device", dracut only
adds the dump target as host devices, which naturally guarantees
only required dracut modules being selected.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-09-06 15:37:15 +08:00
Dave Young
c8ab07e72b Release 2.0.15-12
btw, fixed the bogus date in rpm spec changelog
2017-08-17 16:58:06 +08:00
Dave Young
4384995b3d makedumpfile: fix 4.13 kernel larget vmcore bug
Added patch from panand which was accepted by upstream but not merged in upstream yet.
kexec-tools-2.0.15-makedumpfile-fix-SECTION_MAP_MASK-for-kernel-bigger-than-4.13.patch
2017-08-17 16:50:23 +08:00
Dave Young
fcaa683b01 Revert "Improve 'cpu add' udev rules"
This reverts commit 65d37d19c7.
Since we have no such bugs in Fedora and original rule works fine thus revert it.
2017-08-17 16:42:11 +08:00
Dave Young
238f7d836c Release 2.0.15-11
[From ville.skytta@iki.fi]
- Own the /usr/share/makedumpfile dir
- Mark COPYING as %%license
2017-08-15 09:50:35 +08:00
Dave Young
0ffa712fab Release 2.0.15-10 2017-08-08 10:10:50 +08:00
Pratyush Anand
65d37d19c7 Improve 'cpu add' udev rules
Currently kdump service is restarted even when any new file is added in cpu
subsystem. So, it can be restarted multiple times in the cases like loading
of acpi_cpufreq module or online/offline of any cpu.

However, we should see kdump service restart only once in case a new CPU
is added or removed. cpu crash notes buffer is created when a new CPU is
added. It's location does not change when a CPU is onlined/offlined or
acpi_cpufreq driver is loaded. Therefore, no need to restart kdump
service in such cases.

Thus, we need to introduce an extra filter for the kernel name of the
directory created by cpu_add which is KERNEL=="cpu[0-9]*". This will ensure
that kdump service is not restarted when any new file is added in /removed
from cpu subsystem.

Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-08-08 10:10:35 +08:00
Xunlei Pang
38e6b41c0c module-setup: suppress the early iscsi error messages
Currently, we throw the error message at the very beginning, as
a result on a pure-hardware(all-offload) iscsi machine with many
iscsi partitions, we suffered from too much noise as follows:
  iscsiadm: No records found
  Unable to find iscsi record for
  /sys/devices/pci0000:00/0000:00:06.0/0000:07:00.0/0000:08:01.1/host0/session1
  iscsiadm: No records found
  Unable to find iscsi record for
  /sys/devices/pci0000:00/0000:00:06.0/0000:07:00.0/0000:08:01.3/host1/session2
  iscsiadm: No records found
  Unable to find iscsi record for
  /sys/devices/pci0000:00/0000:00:06.0/0000:07:00.0/0000:08:01.1/host0/session1
  iscsiadm: No records found
  Unable to find iscsi record for
  /sys/devices/pci0000:00/0000:00:06.0/0000:07:00.0/0000:08:01.3/host1/session2
  iscsiadm: No records found
  Unable to find iscsi record for
  /sys/devices/pci0000:00/0000:00:06.0/0000:07:00.0/0000:08:01.1/host0/session1
  iscsiadm: No records found
  Unable to find iscsi record for
  /sys/devices/pci0000:00/0000:00:06.0/0000:07:00.0/0000:08:01.3/host1/session2
  iscsiadm: No records found
  Unable to find iscsi record for
  /sys/devices/pci0000:00/0000:00:06.0/0000:07:00.0/0000:08:01.1/host0/session1
  iscsiadm: No records found
  Unable to find iscsi record for
  /sys/devices/pci0000:00/0000:00:06.0/0000:07:00.0/0000:08:01.3/host1/session2
  iscsiadm: No records found
  Unable to find iscsi record for
  /sys/devices/pci0000:00/0000:00:06.0/0000:07:00.0/0000:08:01.1/host0/session1
  iscsiadm: No records found
  Unable to find iscsi record for
  /sys/devices/pci0000:00/0000:00:06.0/0000:07:00.0/0000:08:01.3/host1/session2
  kexec: loaded kdump kernel
  Starting kdump: [OK]

There's no need to know the very early error messages, we can
remove the error output which is actually normal for the pure
hardware iscsi.

As for unexpected errors, we kept the error outputs in the
succeeding kdump_iscsi_get_rec_val() calls by not appending
"2>/dev/null".

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-08-08 10:10:19 +08:00
Xunlei Pang
2777a93a9c mkdumprd: use 300s as the default systemd unit timeout for kdump mount
Currently, systemd uses 90s as the default mount unit timeout
(see "man 5 systemd-system.conf " for "DefaultTimeoutStartSec"),
in some cases, although it works well in 1st kernel, it's not
enough under kdump and results in mount timeout, further results
in kdump dumping failure.

We've met several such issues, we decided to enlarge this default
value a little for kdump.

We know that dracut has a default initqueue timeout value of 180s
("rd.retry"), we finalized a little larger value 300s as kdump's
default timeout if there is no explicit "DefaultTimeoutStartSec=X,
specified by users.

"DefaultTimeoutStartSec=X" can be overridden by individual mount
option "x-systemd.device-timeout=X", users can specify their own
values as needed.

This patch achieves the purpose by creating a dedicated conf file
"/etc/systemd/system.conf.d/kdump.conf" which has the content of
"DefaultTimeoutStartSec=300s", this is based on the fact that all
the conf files will be parsed by systemd and the last parsed one
will be used if there are duplicate definitions.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-08-08 10:10:03 +08:00
Dave Young
00ceca7f99 Release 2.0.15-9
https://bugzilla.redhat.com/show_bug.cgi?id=1474706

Makedumpfile failed with below error messages, which is caused by kernel changes 65ade2f872b474fa8a04c2d397783350326634e6:

Buffer size for the cyclic mode: 95992
vtop4_x86_64: Can't get the symbol of init_level4_pgt.
readmem: Can't convert a virtual address(ffffffff8fe18284) to physical address.
readmem: type_addr: 0, addr:ffffffff8fe18284, size:390
check_release: Can't get the address of system_utsname.

Pull in Pratyush's fix in upstream makedumpfile (not merged yet but acked by
maintainer)

Signed-off-by: Dave Young <dyoung@redhat.com>
2017-08-07 09:44:42 +08:00
Fedora Release Engineering
1ad0c239a5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild 2017-08-03 00:20:54 +00:00
Florian Weimer
610f08562d Rebuild with fixed binutils for ppc64le (#1475636) 2017-07-30 18:12:58 +02:00
Dave Young
d968a68263 Release 2.0.15-6
Update makedumpfile to upstream 1.6.2

Signed-off-by: Dave Young <dyoung@redhat.com>
2017-07-28 14:42:15 +08:00
Fedora Release Engineering
ee882b26b7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild 2017-07-26 15:08:54 +00:00
Dave Young
06b35b224d Release 2.0.15-4 2017-07-19 09:56:07 +08:00
Xunlei Pang
8fd9f017b2 mkdumprd: remove useless "x-initrd.mount"
After the following systemd commit, "x-initrd.mount"
option became useless actually, we can safely remove
it now.

commit ce3f6d82b003f365f718f24e48f55b8a0372b924
Author: nmartensen <nis.martensen@web.de>
Date:   Fri Jan 15 07:55:25 2016 +0100

    fstab-generator: remove bogus condition

    The sysroot mount is already taken care of by the
    add_sysroot_mount function. With this condition
    left in, we can we can get something like this:

    initrd-root-fs.target.requires
    `-- usr.mount -> /run/systemd/generator/usr.mount

    in the main system (i.e., not in the initramfs). In
    the initramfs, the previous condition already kicks in.

[snip]

"mount_in_initrd(me)" is true with "x-initrd.mount" option,
the behaviour of systemd fstab generator changed after the
above-mentioned patch, it always generates local mount units
required by local-fs.target regardless of "x-initrd.mount".

After failure, it enters dracut emergency, further triggers
kdump emergency service, thus there is no problem.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-07-19 09:51:12 +08:00
Xunlei Pang
9df0cbbeed kdumpctl: use "apicid" other than "initial apicid"
We met a problem on AMD machines, when using "nr_cpus=4" for
kdump, and crash happens on cpus other than cpu0, kdump kernel
will fail to boot and eventually reset.

After some debugging, we found that it stuck at the kernel path
do_boot_cpu()-> ... ->wakeup_secondary_cpu_via_init():
 apic_icr_write(APIC_INT_LEVELTRIG|APIC_INT_ASSERT|APIC_DM_INIT,
            phys_apicid);
that is, it stuck at sending INIT from AP to BP and reset, which
is actually what "disable_cpu_apicid=X" tries to solve. Printing
the value of @phys_apicid showed that it was the value of "apicid"
other that of "initial apicid" showed by /proc/cpuinfo.

As described in x86 specification:
"In MP systems, the local APIC ID is also used as a processor ID by the
BIOS and the operating system. Some processors permit software to modify
the APIC ID. However, the ability of software to modify the APIC ID is
processor model specific. Because of this, operating system software
should avoid writing to the local APIC ID register. The value returned by
bits 31-24 of the EBX register (when the CPUID instruction is executed with a
source operand value of 1 in the EAX register) is always the Initial APIC ID
(determined by the platform initialization). This is true even if software
has changed the value in the Local APIC ID register."

From kernel commit 151e0c7de("x86, apic, kexec: Add disable_cpu_apicid
kernel parameter"), we can see in generic_processor_info(), it uses
a)read_apic_id() and b)@apicid to compare with @disabled_cpu_apicid.

a)@apicid which is actually @phys_apicid above-mentioned is from the
  following calltrace(on the problematic AMD machine):
    generic_processor_info+0x37/0x300
    acpi_register_lapic+0x30/0x90
    acpi_parse_lapic+0x40/0x50
    acpi_table_parse_entries_array+0x171/0x1de
    acpi_boot_init+0xed/0x50f
  The value of @apicid(from acpi MADT) is equal to the value of "apicid"
  showed by /proc/cpuinfo as proved by our debug printk.
b)read_apic_id() gets the value from LAPIC ID register which is "apicid"
  as well.

While the value of "initial apicid" is from cpuid instruction.

One example of "apicid" and "initial apicid" of cpu0 from /proc/cpuinfo
on AMD machine:
  apicid          : 32
  initial apicid  : 0

Therefore, we should assign /proc/cpuifo "apicid" to "disable_cpu_apicid=X".

We've never met such issue before, because we usually tested "nr_cpus=1",
and mostly on Intel machines, and "apicid" and "initial apicid" have the
same value in most cases on Intel machines.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-07-19 09:50:04 +08:00
Dave Young
06c776f36b Release 2.0.15-3 2017-07-14 16:07:11 +08:00
Xunlei Pang
a431a7e354 module-setup: fix 99kdumpbase network dependency
I noticed that network is still enabled for local dumping,
like the following kdump boot message on my test machine
using local disk as the dump target:
  tg3.c:v3.137 (May 11, 2014)
  tg3 0000:02:00.0 eth2: Tigon3 [partno(BCM95720) rev
  (PCI Express) MAC address c8:1f:66:c9:35:0d
  tg3 0000:02:00.0 eth2: attached PHY is 5720C

After some debugging, found it due to a misuse in code below:
  if [ is_generic_fence_kdump -o is_pcs_fence_kdump ]; then
      _dep="$_dep network"
  fi
The "if" condition always results in "true", and should be
changed as follows:
  if is_generic_fence_kdump -o is_pcs_fence_kdump; then
      _dep="$_dep network"
  fi

After this, network won't be involved in non-network dumping,
as for dumpings require network such as nfs/ssh/iscsi/fcoe/etc,
dracut will add network accordingly. And kdump initramfs size
can be reduced from 24MB to 17MB tested on some real hardware,
and from 19MB to 14MB on my kvm. Moreover, it could avoid the
network (driver) initialization thereby saving us more memory.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-07-14 14:54:59 +08:00
Xunlei Pang
fb522e972c mkdumprd: omit dracut modules in case of network dumping
In case of only network target, we can clearly and safely
remove more unnecessary modules to reduce initramfs size,
and to enhance stability.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-07-14 14:54:48 +08:00
Xunlei Pang
821d1af080 mkdumprd: omit dracut modules in case of no dm target
In case of on dm related target, we can clearly and safely
remove many unnecessary modules to reduce initramfs size,
and to enhance stability.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-07-14 14:54:40 +08:00
Xunlei Pang
54a5bcc4ee mkdumprd: omit crypt when there is no crypt kdump target
Resolves: bz1451717
https://bugzilla.redhat.com/1451717

When there is no crypt related kdump target, we can safely
omit "crypt" dracut module, this can avoid the pop asking
disk password during kdump boot in some cases.

This patch introduces omit_dracut_modules() before calling
dracut, we can omit more modules to reduce initrd size in
the future.

We don't want to omit any module for fadump, thus we move
is_fadump_capable() into kdump-lib.sh as a helper to use.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-07-14 14:54:31 +08:00
Xunlei Pang
cb38b32dfc kdumpctl: use generated rd.lvm.lv=X
Resolves: bz1451717
https://bugzilla.redhat.com/1451717

When there is any "rd.lvm.lv=X", "lvm" dracut module will
try to recognize all the lvm volumes which is unnecessary
and probably cause trouble for us.

See https://bugzilla.redhat.com/show_bug.cgi?id=1451717#c2

Remove all the rd.lvm.lv=X inherited from the kernel cmdline,
and generate the corresponding cmdline as needed for kdump.
Because prepare_cmdline() is only used by kdump, we don't need
to add any fadump judgement(also remove the existing judgement
in passing).

Currently, we don't handle "rd.lvm.vg=X", we can add it in
when there is some bug reported in the future.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-07-14 14:54:23 +08:00
Xunlei Pang
9e7b64dc90 mkdumprd: change for_each_block_target() to use get_kdump_targets()
Resolves: bz1451717
https://bugzilla.redhat.com/1451717

Now that we have get_kdump_targets(), use it to simplify the code.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-07-14 14:54:15 +08:00
Xunlei Pang
3ee00cd384 kdump-lib.sh: introduce get_kdump_targets()
Resolves: bz1451717
https://bugzilla.redhat.com/1451717

We need to know all the kdump targets including the dump
target and root in case of "dump_to_rootfs".

This is useful for us to do some extra work related to the
type of different targets.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-07-14 14:54:06 +08:00
Xunlei Pang
1bc78e025f kdump-lib.sh: fix improper get_block_dump_target()
Resolves: bz1451717
https://bugzilla.redhat.com/1451717

This patch improves get_block_dump_target as follows:
-Consider block device in the special "--dracut-args --mount ..."
 in get_user_configured_dump_disk().
-Consider save path instead of root fs in get_block_dump_target(),
 and move it into kdump-lib.sh because we will have another user
 in the following patch.
-For nfs/ssh dumping, there is no need to check the root device.
-Move get_save_path into kdump-lib.sh.

After this patch, get_block_dump_target() can always return the
correct block dump target specified.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-07-14 14:53:43 +08:00
Ziyue Yang
0933f89f65 kdumpctl: fix infinite loop caused by running under bash
Description of problem
(https://bugzilla.redhat.com/show_bug.cgi?id=1465735):
Run `kdumpctl status` as normal user, get below error messages:

Another app is currently holding the kdump lock; waiting for it to exit...
flock: 9: Bad file descriptor
Another app is currently holding the kdump lock; waiting for it to exit...
flock: 9: Bad file descriptor
...

The bug is caused by behavior difference between bash
and sh (bash in posix).

In the function single_instance_lock in kdumpctl script,
there is

exec 9>/var/lock/kdump

which will fail in user mode. However, this fail will cause
script exiting under bash but not exiting under sh, causing
infinite loop because the flock will always fail.

According to the 16th item in
ftp://ftp.gnu.org/old-gnu/Manuals/bash-2.02/html_node/bashref_66.html

If a POSIX.2 special builtin returns an error status, a non-
interactive shell exits.

And according to
https://www.gnu.org/software/bash/manual/html_node/Special-Builtins.html

exec is one of the POSIX.2 special builtin's.

This patch fixes the bug by checking exec return value.

Fixes: 9fb2996d05 ("kdumpctl: change the shebang header to use /bin/bash")
Signed-off-by: Ziyue Yang <ziyang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Reviewed-by: Xunlei Pang <xlpang@redhat.com>
2017-07-14 14:47:37 +08:00
Dave Young
151e0b5345 Release 2.0.15-2 2017-06-28 14:36:01 +08:00
Pratyush Anand
7845cdd89c aarch64: Add makedumpfile executable
Add makedumpfile executable for aarch64 as well.

Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-06-28 14:35:42 +08:00
Dave Young
ff28c8fe08 Release kexec-tools 2.0.15-1 2017-06-23 11:33:25 +08:00
Dave Young
d6dfe2cc1e Release 2.0.14-13 2017-06-15 09:43:11 +08:00
Bhupesh Sharma
f513f035f3 kexec-tools.spec: Fix whitespace errors
This patch fixes the whitespace errors reported by
'rpmlint' or 'fedpkg lint' when they are run on kexec-tools srpm:

kexec-tools.spec:242: W: mixed-use-of-spaces-and-tabs (spaces: line 107,
tab: line 242)

Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-06-15 09:41:33 +08:00
Benjamin Berg
f6303a2a93 dracut-module-setup: Fix test for inclusion of DRM modules
The /sys/modules/*/drivers sysfs entries do not exist anymore on newer
kernels which means that the DRM moduels would never be included.
Instead check if there is any device with a "drm" sysfs directory to
decide on whether DRM modules need to be included.

Acked-by: Dave Young <dyoung@redhat.com>
2017-06-15 09:40:03 +08:00
Pingfan Liu
dcbab02752 kdump.conf.5: clarify the fence_kdump_nodes option
fence_kdump_nodes should include list of cluster node(s) except localhost.

Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-06-09 09:47:22 +08:00
Dave Young
70a9f58336 Release 2.0.14-12 2017-05-18 16:50:48 +08:00
Pingfan Liu
1ca4c9f009 kdumpctl: for fence_kdump, the ipaddr of this node should be excluded from list
kdump should not send fence_kdump notifications to local host, because
the role of the falied node (i.e local host) is to send fence_kdump
notifications to other nodes to tell them I'm kdumping, tell to itself is
nonsense. And we have excluded hostname of local host but when one use ip
address we also need exclude it.

Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-05-18 16:44:42 +08:00
Dave Young
b74479521c Release 2.0.14-11 2017-05-12 11:00:23 +08:00
Xunlei Pang
9fb2996d05 kdumpctl: change the shebang header to use /bin/bash
We met one issue that when changing softlink of "/usr/bin/sh"
to point to "ksh" instead of the default "bash", kdumpctl will
not work and go wrong.

kdumpctl is expected to run under bash like dracut, we should
change its shebang header from "#!/bin/sh" to "#!/bin/bash".

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-05-12 09:58:51 +08:00
Xunlei Pang
2b4b7a6374 kdumpctl: call strip_comments only when necessary to speedup
The "time kdumpctl start" command shows that strip_comments()
consumes lots of cpu time. By only calling it when necessary,
it saves us nearly half second.

Tested on my Fedora kvm machine.
Before this patch:
$ time kdumpctl start
kexec: loaded kdump kernel
Starting kdump: [OK]

real	0m1.849s
user	0m1.497s
sys	0m0.462s

After this patch:
$ time kdumpctl start
kexec: loaded kdump kernel
Starting kdump: [OK]

real	0m1.344s
user	0m1.195s
sys	0m0.195s

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-05-12 09:57:29 +08:00
Xunlei Pang
7f725ef13a Revert "kdumpctl: improve "while read" time for /etc/kdump.conf"
Resolves: bz1449801

"cat $KDUMP_CONFIG_FILE|grep -v "^#"|while read ..." use pipes
to invoke subshells, as a result we met "the dreaded inaccessible
variables within a subshell problem" as described in the book
"Advanced Bash-Scripting Guide".

It cause regressions, so revert it.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-05-12 09:57:29 +08:00
Dave Young
c3ab408727 Release 2.0.14-10
Speedup kdump service startup
2017-05-05 16:16:25 +08:00
Xunlei Pang
38c0b4aa3a kdumpctl: improve "while read" time for /etc/kdump.conf
I found using "cat $KDUMP_CONFIG_FILE|grep -v "^#"|while read ..."
instead of "while read ... do ...; done < $KDUMP_CONFIG_FILE" will
make the script run faster, it saves us nearly half second.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-05-05 16:14:33 +08:00
Xunlei Pang
88a3385e96 kdumpctl: update check_dump_fs_modified() to use "lsinitrd -f"
We use faster "lsinitrd XXX -f usr/lib/dracut/build-parameter.txt"
instead of "lsinitrd XXX | grep "^Arguments:" | head -1", this can
save us around one second.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-05-05 16:14:33 +08:00
Xunlei Pang
2a5f362521 kdumpctl: improve check_wdt_modified()
Use the logic of dracut 04watchdog/module-setup.sh to check,
then we only need to compare the content of 00-watchdog.conf,
so we can save one operation of lsinitrd.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-05-05 16:14:33 +08:00
Xunlei Pang
c63c0a1084 kdumpctl: remove is_mode_switched()
handle_mode_switch() can ensure the correct logic, so remove
the needless is_mode_switched(). This helps to save one slow
lsinitrd operation for each boot.

Improved backup_default_initrd() to judge DEFAULT_INITRD.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-05-05 16:14:33 +08:00
Xunlei Pang
071ea2a277 kdumpctl: bail out earlier in case of no reserved memory
Some cloud people complained that VM boot speed is slower than
Ubuntu and other distributions, after some debugging, we found
that one of the causes is kdump service starts too slow(7seconds
according to the test result on the test VM), actually there is
no "crashkernel=X" specified. Although kdump service is parallel,
it affects the speed more or less especially on VMs with few cpus,
which is unacceptable. It is even worse when kdump initramfs is
built out in case of no reserved memory at first boot.

Commit afa4a35d3 ("kdumpctrl: kdump feasibility should fail if no
crash memory") can actually solve this issue.

This patch is a supplement of above-mentioned commit, we bail out
start() even earlier in case of no reserved memory.

Also made some cosmatic changes for check_crash_mem_reserved().

1) Before this patch
$ time kdumpctl start
No memory reserved for crash kernel.
Starting kdump: [FAILED]

real    0m0.282s
user    0m0.184s
sys     0m0.146s

2) After this patch
$ time kdumpctl start
No memory reserved for crash kernel
Starting kdump: [FAILED]

real    0m0.010s
user    0m0.008s
sys     0m0.001s

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-05-02 17:23:57 +08:00