kdumpctl passes --device argument if dump target is a raw device. It passes
--mount argument if dump target is either mounted as nfs or as a bulk
device. When dump target device is a root device then it does not pass any
of the above two arguments.
After kdumpctl restart, if there is any change in file system which needs
different dracut arguments, then initramfs must be rebuild.
Modification in filesystem for a raw target does not affect dracut
arguments. So, we do not consider to check any modification if raw target
was specified in kdump.conf.
We might need to change dracut arguments if there is some changes in nfs
and ssh target related files. However, we do not consider them in this
patch.
We mainly consider changes in bulk target specified in kdump.conf. We also
consider changes in bulk and nfs file system, if there was no dump target
specified in kdump.conf but dump path is mounting such file systems.
So the initramfs must be rebuild if, either dump target's persistent path
or it's mount point or its file system type changes. If there is no dump
target specified then, both dump path and root path must mount same device,
otherwise rebuild should be triggered.
Some of the examples when we can need a rebuild:
-- "dump target" is specified as one of ext[234], xfs or btrfs. But after
kdump initramfs building its UUID is changed by reformatting.
-- "dump target" is specified as file system type fs1 (say ext3). But after
kdump initramfs building, user change it to fs2 (say ext4), probably by
a mkfs.ext4 executing on the target device.
-- "dump target" is not specified, but "dump path" mounts a device which
is different than device for root path and either UUID or file system type
is modified after kdump initramfs build.
-- "dump target" is not specified, but "dump path" mounts a nfs device and
nfs host path changes after kdump initramfs build.
Some testing:
Initial conditions:
-- No dump target specified
-- dump path (/var/crash) and root(/) are on same device
-- kdumpctl was already executed once after last modification in
/etc/kdump.conf
# kdumpctl restart
No rebuild
# mkfs.ext2 /dev/md0;mount /dev/md0 /var/crash/;kdumpctl restart
Rebuilt because "Detected change in File System"
# kdumpctl restart
No rebuild
# umount /var/crash/;kdumpctl restart
Rebuilt because "Detected change in File System"
# kdumpctl restart
No rebuild
# mount /dev/md0 /var/crash/;kdumpctl restart
Rebuilt because "Detected change in File System"
# umount /var/crash;mkfs.ext4 /dev/md0;
# mount /dev/md0 /var/crash/;kdumpctl restart
Rebuilt because "Detected change in File System"
# umount /var/crash;mkfs.ext4 /dev/mapper/fedora-swap
# mount /dev/mapper/fedora-swap /var/crash/
# kdumpctl restart
Rebuilt because "Detected change in File System"
# umount /var/crash;mkfs.btrfs /dev/mapper/fedora-swap -f
# mount /dev/mapper/fedora-swap /var/crash/
# kdumpctl restart
Rebuilt because "Detected change in File System"
# kdumpctl restart
No rebuild
# umount /var/crash/;kdumpctl restart
Rebuilt because "Detected change in File System"
# mount /dev/mapper/fedora-swap /var/crash/;kdumpctl restart
Rebuilt because "Detected change in File System"
# umount /var/crash;mkfs.minix /dev/md0
# mount /dev/md0 /var/crash/; kdumpctl restart
Rebuilt because "Detected change in File System"
# kdumpctl restart
No rebuild
# umount /var/crash/;kdumpctl restart
Rebuilt because "Detected change in File System"
# mount 192.168.1.16:/nfsroot /var/crash/;kdumpctl restart
Rebuilt because "Detected change in File System"
# umount /var/crash/;kdumpctl restart
Rebuilt because "Detected change in File System"
# mount 192.168.1.16:/nfsroot /var/crash/;kdumpctl restart
Rebuilt because "Detected change in File System"
# kdumpctl restart
No rebuild
# umount /var/crash;mount 192.168.1.12:/nfsroot /var/crash/
# kdumpctl restart
Rebuilt because "Detected change in File System"
# umount /var/crash/;kdumpctl restart
Rebuilt because "Detected change in File System"
Added "raw /dev/md0" in /etc/kdump.conf
# kdumpctl restart
Rebuilt because "Detected change in /etc/kdump.conf"
# mkfs.ext4 /dev/md0 ;kdumpctl restart
No rebuild
Added "ext4 /dev/md0" in /etc/kdump.conf
# mkfs.ext4 /dev/md0;mount /dev/md0 /mnt
# mkdir /mnt/var;mkdir /mnt/var/crash; kdumpctl restart
Rebuilt because "Detected change in /etc/kdump.conf"
# umount /mnt;mkfs.ext4 /dev/md0;mount /dev/md0 /mnt
# mkdir /mnt/var;mkdir /mnt/var/crash; kdumpctl restart
Rebuilt because "Detected change in /etc/kdump.conf"
Most of the credits for this patch goes to Xunlei Pang <xpang@redhat.com>
for suggesting several improvements.
Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Baoquan He <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Relevant kdump files are also part of system. Therefore, moving logic of
file modification checking in check_system_modified() function now.
No functional changes.
Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Baoquan He <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
There could be some dynamic system modification, which may affect kdump
kernel boot process. In such situation initramfs must be rebuilt on the
basis of changes.
Since most of these checking methods will use information from
TARGET_INITRD, therefore check its existence in common code.
Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Baoquan He <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
When $KDUMP_BOOTDIR is RO then kexec-tools should not try rebuild initramfs
even when conditions for rebuild is met.
Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Use KDUMP_COMMANDLINE_REMOVE config instead of hardcode them in
kdumpctl, which makes it possible system admins decide what params to
remove such as "quiet" or other debug flags.
This patch also adds backward compatibility even if an old config is
used. It will behave the same as the old version.
Signed-off-by: Dangyi Liu <dliu@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
slub_debug parameter enables debug for slub, making each object take
more memory than normal. During a typical kdump, "slub_debug=FZPU" will
cost about 33MB additional memory. If users really want to enable this
parameter, they should specify it in KDUMP_COMMANDLINE_APPEND.
Signed-off-by: Dangyi Liu <dliu@redhat.com>
According to man page, default option can only use reboot, halt, poweroff,
shell and dump_to_rootfs as parameter.
Currently, if configuration kdump.conf is:
------
path /var/crash
core_collector makedumpfile -nosuchfile
default no_such_option
------
kdump service still can be started.
Adding function "check_default_config" to kdumpctl file can solve
this problem.
I have tested this patch in my test machine(Fedora-21).
v1 --> v2
Baoquan He point "check_default_config" function should be call in
"check_config" function.
Wang Li point if kdump.conf donesn't configure the "default" option,
kdump serivce will fail.
Signed-off-by: Qiao Zhao <qzhao@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Minfei Huang <mhuang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
For Atomic system, the cmdline will contain the specific string
"ostree". So we can filter out the "ostree" to judge the system is
Atomic or not.
Signed-off-by: Minfei Huang <mhuang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Previously /boot is asumed as the default dir where kernel and initrd
is put. However, the directory containing the running kernel image
on Atomic systems differs in each installation. Usually something like:
/boot/ostree/rhel-atomic-host-b50a015b637c353dc6554c851f8a1212b60d6121a7316715e4a63e2a4113cd72
This means that kdump will not find vmlinuz when installed on an
Atomic host, and thus the kdump service will fail to start.
In this patch, the kdump boot dir finding behaviour is a little changed.
Firstly check whether user has specify a directory explicitly in
/etc/sysconfig/kdump. If yes that is respected. Otherwise we assume
1st kernel and kdump kernel are put in the same place under /boot.
Then find it according /proc/cmdline and append it to /boot/
Note:
So now the KDUMP_BOOTDIR in /etc/sysconfig/kdump is set as empty
by default. If user set KDUMP_BOOTDIR to a directory, then he need to
take care of all related things himself. otherwise kdump script handle
it automatically.
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: Minfei Huang <mhuang@redhat.com>
kdumpctl now parses mount points in determining the partition to
save the dump to. So /etc/fstab can be considered a configuration
file for kdump.
Change adds an additional depenedency check on /etc/fstab when
kdump is restarted.
Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com>
Acked-by: WANG Chao <chaowang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
With the inclusion of 'panic_on_warn',
http://marc.info/?l=linux-api&m=141570937328528&w=2
and which is now staged in Andrew Morton's tree, we need to remove
'panic_on_warn' from the 2nd kernel's cmdline. If it is included it is
possible a non-fatal warning could panic the second kernel.
Before:
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0+
root=/dev/mapper/rhel_intel--canoepass--05-root ro
rd.lvm.lv=rhel_intel-canoepass-05/root
rd.lvm.lv=rhel_intel-canoepass-05/swap console=ttyS0,115200n81
LANG=en_US.UTF-8 systemd.debug panic_on_warn=1 irqpoll nr_cpus=1
reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2
panic=10 rootflags=nofail acpi_no_memhotplug disable_cpu_apicid=0
elfcorehdr=839092K
After:
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0+
root=/dev/mapper/rhel_intel--canoepass--05-root ro
rd.lvm.lv=rhel_intel-canoepass-05/root
rd.lvm.lv=rhel_intel-canoepass-05/swap console=ttyS0,115200n81
LANG=en_US.UTF-8 systemd.debug irqpoll nr_cpus=1 reset_devices
cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10
rootflags=nofail acpi_no_memhotplug disable_cpu_apicid=0
elfcorehdr=839092K
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Now kexec file based syscall can be used with secureboot enabled machines.
Automatically switch to using new syscall if secureboot is enabled on the
machine.
Also remove the old message where kdump service failed if secureboot is
enabled. That's not the case anymore.
v2:
Renamed "secureboot" to "Secure Boot" in user visible message.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Currently old kexec syscall denies unloading a kernel if secureboot is enabled.
I think this is not right behavior and should be changed. But for now, use
new syscall if secureboot is enabled and that allows unloading kernel.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Does anybody know why are we redirecting stderr to /dev/null when using
kexec load/unload commands? This sounds wrong to me. In case of error I
have no idea what went wrong.
Systemctl already puts all the information in journal. So if we are worried
that user will be bombarded with error messages, that should not be a concern.
So do not redirect stderr to /dev/null.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
When there's no kdump initramfs for lsinitrd to inspect with, there will
be an error:
# kdumpctl start
/boot/initramfs-3.16.0-rc7+kdump.img does not exist
Usage: lsinitrd [options] [<initramfs file> [<filename> [<filename> [...] ]]]
Usage: lsinitrd [options] -k <kernel version>
-h, --help print a help message and exit.
-s, --size sort the contents of the initramfs by size.
-m, --mod list modules.
-f, --file <filename> print the contents of <filename>.
-k, --kver <kernel version> inspect the initramfs of <kernel version>.
No kdump initial ramdisk found.
Rebuilding /boot/initramfs-3.16.0-rc7+kdump.img
[..]
In addition, lsinitrd is a slow operation. We only run it when it's
fadump mode, to speed up in kdump mode.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
In fadump, in case of failure while rebuilding initrd, the error status
is not handled properly. See code snippet below:
$MKDUMPRD $target_initrd_tmp --rebuild $TARGET_INITRD --kver $kdump_kver \
-i /tmp/fadump.initramfs /etc/fadump.initramfs
rm -f /tmp/fadump.initramfs
if [ $? != 0 ]; then
echo "mkdumprd: failed to rebuild initrd with fadump support" >&2
return 1
fi
This patch fixes this issue
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
The script dracut-kdump.sh is responsible for capturing vmcore during
second kernel boot. Currently this script gets installed into kdump
initrd as part of kdumpbase dracut module.
With fadump support, 'dracut-kdump.sh' script also gets installed into
default initrd to capture vmcore generated by firmware assisted dump.
Thus in fadump case, the same initrd is going to be used for normal
boot as well as boot after system crash. Hence a check is required to
see if it is a normal boot or boot after crash.
A new node "ibm,kernel-dump" is added, to the device tree, by firmware
to notify kernel if it is booting after crash. The below patch adds a
check for this node before executing steps to capture vmcore. This
check will help bypassing the vmcore capture steps during normal boot
process.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
The current kdump infrastructure builds a separate initrd which then
gets loaded into memory by kexec-tools for use by kdump kernel. But
firmware assisted dump (FADUMP) does not use kexec-based approach.
After crash, firmware reboots the partition and loads grub loader
like the normal booting process does. Hence in the FADUMP approach,
the second kernel (after crash) will always use the default initrd
(OS built). So, to support FADUMP, change is required, as in to add
dump capturing steps, in this initrd.
The current kdumpctl script implementation already has the code to
build initrd using mkdumprd. This patch uses the new '--rebuild'
option introduced, in dracut, to incrementally build the initramfs
image. Before rebuilding, we may need to probe the initrd image for
fadump support, to avoid rebuilding the initrd image multiple times
unnecessarily. This can be done using "lsinitrd" tool with the newly
proposed '--mod' option & inspecting the presence of "kdumpbase" in
the list of modules of default initrd image. We rebuild the image if
only "kdumpbase" module is missing in the initrd image. Also, before
rebuilding, a backup of default initrd image is taken.
Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree
kdump module for dracut, which is responsible for adding vmcore
capture steps into initrd, if dracut is invoked with "IN_KDUMP"
environment variable set to 1. mkdumprd script exports "IN_KDUMP=1"
environment variable before invoking dracut to build kdump initrd.
This patch relies on this current mechanism of kdump init script.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
During service kdump stop, if firmware assisted dump is enabled
and running, then stop firmware assisted dump by echo'ing 0 to
'/sys/kernel/fadump_registered' file.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
During service kdump start, if firmware assisted dump is not enabled then
fallback to starting of existing kexec based kdump. If firmware assisted
is enabled but not running, then start firmware assisted dump by echo'ing
1 to '/sys/kernel/fadump_registered' file.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
This patch enables kdump script to check if firmware-assisted dump is
enabled or not by reading value from '/sys/kernel/fadump_enabled'. The
determine_dump_mode() routine sets dump_mode to 'fadump', if fadump is
enabled. By default, dump_mode is set to 'kdump' mode.
Modify status routine to check if firmware assisted dump is registered
or not by reading value from '/sys/kernel/fadump_registered' file. If
it is set to '1' then return status=0 else return status=1.
0 <= Firmware assisted is enabled and running
1 <= Firmware assisted is enabled but not running
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
This cleanup patch removes unnecessary keyword "function" at all places in
kdumpctl script. Also, corrects couple of typos in the script.
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Vivek suggested we should display message while waiting for the lock,
because the waiting could be long and user will have no idea what's
going on.
So we will repeat the following message every 5 seconds while waiting:
"Another app is currently holding the kdump lock; waiting for it to exit..."
Thanks Vivek for providing a more comprehensive message.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Adds two new options to kdump.conf to be able to configure fence_kdump
support for generic clusters:
fence_kdump_args <arg(s)>
- Command line arguments for fence_kdump_send (it can contain all
valid arguments except hosts to send notification to)
fence_kdump_nodes <node(s)>
- List of cluster node(s) separated by space to send fence_kdump
notification to (this option is mandatory to enable fence_kdump)
Generic clusters fence_kdump configuration take precedence over older
method of fence_kdump configuration for Pacemaker clusters. It means
that if fence_kdump is configured using above options in kdump.conf, old
Pacemaker configuration is not used even if it exists.
Bug-Url: https://bugzilla.redhat.com/1078134
Signed-off-by: Martin Perina <mperina@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Renames check_fence_kdump to check_pcs_fence_kdump to clearly identify
that this method checks only Pacemaker configuration of fence_kdump.
Bug-Url: https://bugzilla.redhat.com/1078134
Signed-off-by: Martin Perina <mperina@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Renames is_fence_kdump to is_pcs_fence_kdump to identify that this
method should be used to detect fence_kdump configuration only in
Pacemaker clusters.
Bug-Url: https://bugzilla.redhat.com/1078134
Signed-off-by: Martin Perina <mperina@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Renames FENCE_KDUMP_CONFIG variable to FENCE_KDUMP_CONFIG_FILE to
distinguish it from values read from fence_kdump_args option in
kdump.conf (introduced in following patches).
Bug-Url: https://bugzilla.redhat.com/1078134
Signed-off-by: Martin Perina <mperina@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
== Version 2 ==
Addresses Vivek's review comments:
1. Don't force numeric in awk script snipet.
2. Command line processing is moved from load_kernel to new function
"prepare_cmdline." This new function is responsible for
setting up the command line passed to KEXEC.
3. New function "append_cmdline" is added to append {argument,value}
pair to command line if argument is not already present.
== Version 1 ==
A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple
processors in the crash kernel.
To do this safely the crash kernel needs to know which CPU was the 1st
kernel BSP (bootstrap processor) so that the crash kernel will NOT send
the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel
BSP, some systems may reset or hang.
The EFI spec doesn't require that any particular processor is chosen
as the BSP and the CPU (and its apic id) can change from one boot to
the next. Hence automating the selection of CPU to disable if the
system would panic is desired.
This patch updates the kdumpctl script to get the "initial apicid"
of CPU 0 in the first kernel and will pass this as the
"disable_cpu_apicid=" arguement to kexec if it wasn't explicitly
set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND.
CPU 0 is chosen as it is the processor thats execute the OS
initialization
code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.)
See associated Red Hat Bugzilla(s) for additional background material:
https://bugzilla.redhat.com/show_bug.cgi?id=1059031https://bugzilla.redhat.com/show_bug.cgi?id=980621
Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Description of problem:
Previously with selinux in enforcing mode, could prevent ssh-keygen from
generating keys. Support for selinux policy for allowing applications to
access ssh-keygen for generating ssh keys was added in
selinux-policy-3.7.19-126.el6_2.6.
Solutions:
Because of the context was added for ssh key generation, so the keys were
generated without fliping from enforcing mode to permissive mode for ssh
key generation. This patch removes selinux code which switches between
enforcing and permissive modes.
Signed-off-by: arthur <zzou@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Move the code to check /sys/kernel/kexec_crash_loaded to function
check_kdump_feasibility(). And rename status() to check_current_kdump_status()
so these two functions become clearer.
cleanup kdumpctl status path as well.
Tested with kernel without CONFIG_KEXEC
Tested with run kdumpctl start two times.
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Kdump does not support secure boot yet, so let's claim it is not supported
at the begginning of service start function.
In this patch for checking secure boot status I'm checking the efivars per
suggestion from pjones. see in code comments for the details.
Tested in Fedora 19 + qemu ovmf with secure boot enabled.
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
If the system is configured fence kdump, we need to update kdump
initramfs if cluster or fence_kdump config is newer.
In RHEL7, cluster config is no longer keeping locally but stored
remotely. Fortunately we can use a pcs tool to retrieve the xml based
config and parse the last changed time from that.
/etc/sysconfig/fence_kdump is used to configure runtime arguments to
fence_kdump_send. So We have to pass the arguments to 2nd kernel.
When cluster config or /etc/sysconfig/fence_kdump is newer than local
kdump initramfs, we must rebuild initramfs to adapt changes in cluster.
For example:
Detected change(s) the following file(s):
cluster-cib /etc/sysconfig/fence_kdump
Rebuilding /boot/initramfs-xxxkdump.img
[..]
Signed-off-by: WANG Chao <chaowang@redhat.com>
Tested-by: Zhi Zou <zzou@redhat.com>
Tested-by: Marek Grac <mgrac@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
We only allow one instance of kdump service running at each time by
flock /var/lock/kdump which is opened as fd 9 in kdumpctl script.
However a leaking fd issue has been discovered by SELinux:
When executing a specific shell command (not the shell built-in but
provided by other packages, in this case - restorecon) in kdumpctl,
current shell will fork a new subshell for executing and
the subshell will inherit open fd 9 from parent shell. And SELinux
detects that subshell is holding the open fd and consider fd 9 is
leaked.
To avoid this kind of leaking, the most easy way seems to be breaking our
kdumpctl code out into two parts:
- A top level parent shell, which is only used to deal with the lock and
invoking the subshell below.
- A 2nd tier level subshell, which is closing the inherited open fd at
very first and doing the rest of the kdumpctl job. So that it isn't
leaking fd to its subshell when executing like restorecon, etc.
To be easy to understand, the callgraph is roughly like below:
[..]
--> open(9)
--> flock(9)
--> fork
--> close(9) <-- we close 9 right here
--> main() <-- we're now doing the real job
--> [..]
--> fork()
--> restorecon <-- we don't leak fd 9 to child process
--> [..]
--> [..]
As shown above, a wrapper main() is added as the 2nd tier level shell in
this kind of call model. So we can completely avoid leaking fd to
subshell.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
From: Wade Mealing <wmealing@redhat.com>
The RHEL 5 release of mkdumprd allowed for comments in the kdump config
file as shown below:
net 192.168.1.1 # this is the comment part
This patch strips them out during processing, but leaves the configuration
file in original condition.
Signed-off-by: Wade Mealing <wmealing@redhat.com>
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
There will be a race condition if multiple kdumpctl instances are
running at the same time.
By introducing a global mutex lock, only one instance can acquire this
lock and run, others will be waiting for the lock in queue. Now each
kdump instance will be run in serial order and there won't any race
condition.
This is a patch backported from RHEL6.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2nd kernel has very limited memory. Allocating huge pages will probably
trigger OOM. So let's remove hugepages and hugepagesz kernel parameters
for 2nd kernel when 1st kernel are using them.
If user wants huge pages cmdline in 2nd kernel, he/she can still specify
it through KERNEL_COMMANDLINE_APPEND in /etc/sysconfig/kdump.
This patch adds a new function remove_cmdline_param(). It takes a list
of kernel parameters as its arguments and remove them from given kernel
cmdline.
update:
1. Add description of remove_cmdline_param() per Vivek.
2. Remove_cmdline_param() will take kernel cmdline as $1, then strip it
and print the result.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Dracut root fs is always mounted, but it's not guaranteed to success
because we are in crash/kdump context. So selinux policy can not only
depends on chroot load_policy.
Per discussion with Vivek and Selinux people, relabel kdump files
when the service restart.
Currently only below cases are considerd:
1. target mounted in 1st kernel
2. target mounted as rw, if user mount it as 'ro' they will have to
relabel the files by themselves.
3. save path is not masked, this means if /var/crash is mount to another
disk which is different from dump target it will not visible to user
so user need manually relabel them.
4. only local filesystem based targets.
Tested on F19 machine.
Tested local fs dump and network dump along with different save path
to address above mentioned cases.
Vivek: use function name is_dump_target_configured
use getfattr -m "security.selinux" instead of ".*"
Daniel: use restorecon instead of chcon.
dyoung: keep minix in local fs list since it has not been deperacated yet.
Vivek: wrap is_dump_target_configured checking in function path_to_be_relabeled
dyoung: use awk instead of cut to print config value for different
space delimeters
dyoung: mute df error message: `df $_mnt/$_path 2>/dev/null`
For nfs restorecon, since it will be in 3.11 kernel, we can add it when it's
ok in Fedora.
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
mkdumprd call dracut to rebuilding kdump initrd, sometimes passing extra
dracut args is helpful. For example user can enable debug output with
--debug, --printsize to print roughly increased initramfs size by each module,
--omit-drivers to omit kernel modules, etc.
This patch enables dracut_args option for passing extra args to dracut.
Also it modifies add_dracut_arg() to treat a string with-in quote as single
string because for dracut options which has its own args, the args need to be
quoted and space seperated.
If add_dracut_arg() gets an string read from kdump.conf and if that string
contains double quotes, then while converting to positional parameters
those double quotes are not interpreted. Hence if /etc/kdump.conf contains
following.
dracut_args --add-drivers "driver1 driver2"
then add_dracut_args() sees following positional parameters
$1= --add-drivers
$2= "driver1
$3= driver2"
Notice, double quotes have been ignored and parameters have been broken
based on white space.
Modify add_dracut_arg() to look for parameters starting with " and
if one is found, it tries to merge all the next parameters till one
is found with ending double quote. Hence effectively simulating
following behavior.
$1= --add-drivers
$2= "driver1 driver2"
[v1->v2]: address quoted substring in dracut_args, also handle the leading
and ending spaces in substring.
[v2->v3]: fix dracut arguments seperator in kdump.conf.
[v3->v4]: improve changelog, thanks vivek.
[v4->v5]: make the manpage more verbose [vivek].
Tested with below dracut_args test cases:
1. dracut_args --add-drivers "pcspkr virtio_net" --omit-drivers "sdhci-pci hid-logitech-dj e1000"
2. dracut_args --add-drivers " pcspkr virtio_net " --omit-drivers "sdhci-pci hid-logitech-dj e1000"
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Current blacklist option is different from the option in rhel6. In current
implementation blacklist just means omit the driver, but it should really
be preventing it being loaded in initramfs.
To keep consistent, just make the option as deprecated. User is suggested
to user dracut kernel cmdline rd.driver.blacklist instead.
[v1->v2]: improve man page description, thanks Vivek.
Tested in kvm guest with rd.driver.blacklist in kdump sysconfig
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Add a function check_config to check kdump config file.
1. move multi dump target checking into this function
2. check invalid config options and obsolete config options
3. check null config value.
[v2->v3]: add detail doc about deprecated options in kdump.conf manpage.
[v3->v4]: print out the bad config option in case it is not valid.
[v4->v5]: improve documentation according to comments from Vivek.
[v5->v6]: s/Deprecated/Invalid for invalid config options.
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Marc Milgram <mmilgram@redhat.com>
check_config is actually checking the files timestamp and rebuilding initrd.
Rename it to check_rebuild instead thus check_config can be used for checking
config file valid or not.
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
In old code, kdumpctl program exit directly when check_ssh_target failed
without printing "Starting kdump: FAILED". Then when manually invoke
"kdumpctl restart", only print "Stopping kdump: OK", but no "Starting
kdump: FAILED". That is unreasonable.
In this patch change check_ssh_target() to return when it failed. Then
check the returned value in start() function and print status if the
returned value is not 0.
Meanwhile change "space" to "tab" in function check_ssh_target(), make
those be consistent with the whole script file.
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
In kdumpctl, some printings are incomplete, like "Starting kdump:" or
"Stopping kdump:". Now add the service status to the end of such kind
of printing.
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
In fedora, systemd take control of services. During bootup and manually
invoke "systemctl restart kdump.service", the standard Output/Error
are all redirected to journal/syslog. Then particular LOGGER is useless
in kdumpctl.
In this patch, remove codes related to LOGGER. But for noticing user,
trying to add substituted printing to Standard Output/Err.
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Resolves: bz866357
MEM_RESERVED is for checking if crash memory is reserved or not.
Originally it use /proc/iomem for x86, parsing /proc/cmdline for ppc.
This cause problems for crashkernel=auto, because it does not fit for
the regular expression of [0-9]\+[MmKkGg]@[0-9]\+[MmGgKk]
Fix this by use /sys/kernel/kexec_crash_size for all arches.
After the fix the code is more clear than before.
[v1->v2] vivek: add space between "crash kernel"; remove misleading warning.
Tested-by: Chao Wang <chaowang@redhat.com>
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
We can use not only space but also tab as whitespace,
so s/\ /[[:blank:]] for checking the whitespace
The last commit is intend for checking multiple dump target,
and differentiate ssh and sshkey options. This issue is only
for ssh, so no need to add [[:blank:]] for other dump types to
create a very long code line.
[v1->v2]: use [[:blank:]] instead of [[:space:]]
see expanation in below doc:
http://en.wikipedia.org/wiki/Regular_expression#POSIX_character_classes
[:blank:] [ \t] Space and tab
[:space:] [ \t\r\n\v\f] Whitespace characters
Tested the [:blank:] works well as [:space:]
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
CC: Cong Wang <amwang@redhat.com>
Resolves: bz867703
For both ssh and sshkey specified in kdump.conf, we will error out:
[..]
+ start
+ local nr
++ awk 'BEGIN{cnt=0} /^raw|^ssh|^nfs|^ext[234]|^xfs|^btrfs|^minix/{cnt++} END{print cnt}' /etc/kdump.conf
+ nr=2
+ '[' 2 -gt 1 ']'
+ echo -n 'Error: More than one dump targets specified'
Error: More than one dump targets specified+ echo
Fix this by Improving the patterns for multi dump targes checking
with one more space.
Thanks ChaoWang for catching this and providing the fix.
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Add force_rebuild option in kdump.conf
Some user need always force rebuild the dumprd, add an kdump.conf
option force_rebuild here. If force_rebuild is set to 1
kdump initrd will be rebuilt every time then the service starts.
Testing:
Tested below cases:
force_rebuild
force_rebuild 0
force_rebuild 1
force_rebuild 2
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Currently net options means either nfs or ssh dump.
Better to split these two into standalone options. That's more clear to user.
after the split, ssh dump need user specify "ssh user@host"
nfs dump need user specify "nfs host:nfsshare"
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
we now switched to systemd, 'service kdump propagate' does not work anymore.
update the alert message to use 'kdumpctl propagate'
vivek: update kexec-kdump-howto.txt as well.
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
