I have a freshly installed jessie system (which is running systemd, not
SysV init) and I am having trouble reproducing most of these issues. Let
me address these one at a time below.
On 05/19/2015 07:15 AM, Thomas Stangner wrote:
Package: kexec-tools
Version: 1:2.0.7-5
Severity: grave
Tags: patch
Rebooting via kexec is currently broken when using the default init system of
Jessie (systemd) and may result in filesystem corruption or other unwanted
effects of improperly shutdown services. This bug does not apply when using the
SysV init system.
Reboots (e.g. via 'reboot', 'systemctl kexec' or 'systemctl reboot') will cause
the LSB SysV scripts of kexec-tools (/etc/init.d/kexec-load and
/etc/init.d/kexec) to be stopped BEFORE reaching the systemd kexec target (and
other systemd targets), which means that other LSB init scripts and/or systemd
services will be in a race condition with the LSB kexec script and the
filesystems may not be properly unmounted beforce /etc/init.d/kexec calls
/sbin/kexec -e.
As an effect of this, after rebooting via kexec, one may often observe orphaned
inodes or other filesystem incosistencies, especially on a busy machine with
heavy IO.
/etc/init.d/kexec script header says:
# X-Stop-After: umountroot
which means stop target for /etc/init.d/kexec will not be called until
root fs has been unmounted, at which point all other filesystems must
have already been unmounted.
Have you seen any evidence of corruption on a filesystem?
There also seems to be logical error in the /etc/init.d/kexec-load LSB script,
because the kexec image will only get loaded when the systemd target is reboot
- when the target is kexec, the image won't be loaded and thus a normal reboot
will occur.
Rebooting the system with "reboot" calls the target reboot. If one
invokes the target kexec directly, their intent is to kexec immediately
(same as exceuting "kexec -e" which does not do an orderly shutdown).
Orderly shutdown is meant to happen when reboot is called, not when
kernel is kexec'd explicitly by the user. I do not agree with this change.
The following patch for the source package should fix this and make rebooting
via 'systemctl kexec' possible (when /etc/default/kexec has LOAD_KEXEC
enabled), 'reboot' or 'systemctl reboot' will result in normal reboots.
--- debian/kexec.init.d.org 2014-07-25 19:03:25.000000000 +0200
+++ debian/kexec.init.d 2015-05-19 14:26:40.680256999 +0200
@@ -36,7 +36,10 @@
exit 3
;;
stop)
- do_stop
+ # Only execute, when running with SysV, systemd has its own kexec target
+ if [ ! -d /run/systemd/system ] ; then
+ do_stop
+ fi
This causes systems running systemd to do a normal full reboot, not a
kexec reboot. I applied this change to a freshly installed jessie system
running systemd and confirmed lack of kexec reboot with this change.
;;
*)
echo "Usage: $0 start|stop" >&2
--- debian/kexec-load.init.d.org 2014-11-24 05:02:10.000000000 +0100
+++ debian/kexec-load.init.d 2015-05-19 14:27:43.431537728 +0200
@@ -102,9 +102,9 @@
;;
stop)
# If running systemd, we want kexec reboot only if current
- # command is reboot
+ # target is kexec
if [ -d /run/systemd/system ]; then
- systemctl list-jobs systemd-reboot.service | grep -q
systemd-reboot.service
+ systemctl list-jobs systemd-kexec.service | grep -q
systemd-kexec.service
if [ $? -ne 0 ]; then
exit 0
fi
This change also bypasses kexec reboot and does a normal reboot. Again
confirmed on a freshly installed jessie system.
--
Khalid
-- System Information:
Debian Release: 8.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages kexec-tools depends on:
ii debconf [debconf-2.0] 1.5.56
ii libc6 2.19-18
kexec-tools recommends no packages.
kexec-tools suggests no packages.
-- debconf information:
* kexec-tools/load_kexec: true
kexec-tools/use_grub_config: false
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
