kexec-tools/dracut-kdump-emergency.target
Xunlei Pang 5c87d73cf3 kdump-emergency: fix "Transaction is destructive" emergency failure
We met a problem that the kdump emergency service failed to
start when the target dump timeout(we passed "rd.timeout=30"
to kdump), it reported "Transaction is destructive" messages:

  [ TIME ] Timed out waiting for device dev-mapper-fedora\x2droot.device.
  [DEPEND] Dependency failed for Initrd Root Device.
  [ SKIP ] Ordering cycle found, skipping System Initialization
  [DEPEND] Dependency failed for /sysroot.
  [DEPEND] Dependency failed for Initrd Root File System.
  [DEPEND] Dependency failed for Reload Configuration from the Real Root.
  [ SKIP ] Ordering cycle found, skipping System Initialization
  [ SKIP ] Ordering cycle found, skipping Initrd Default Target
  [DEPEND] Dependency failed for File System Check on /dev/mapper/fedora-root.
  [  OK  ] Reached target Initrd File Systems.
  [  OK  ] Stopped dracut pre-udev hook.
  [  OK  ] Stopped dracut cmdline hook.
           Starting Setup Virtual Console...
           Starting Kdump Emergency...
  [  OK  ] Reached target Initrd Default Target.
  [  OK  ] Stopped dracut initqueue hook.
  Failed to start kdump-error-handler.service: Transaction is destructive.
  See system logs and 'systemctl status kdump-error-handler.service' for details.
  [FAILED] Failed to start Kdump Emergency.
  See 'systemctl status emergency.service' for details.
  [DEPEND] Dependency failed for Emergency Mode.

This is because in case of root failure, initrd-root-fs.target
will trigger systemd emergency target which requires the systemd
emergency service actually is kdump-emergency.service, then our
kdump-emergency.service starts kdump-error-handler.service with
"systemctl isolate"(see 99kdumpbase/kdump-emergency.service, we
replace systemd's with this one under kdump).

This will lead to systemd two contradictable jobs queued as an
atomic transaction:
job 1) the emergency service gets started by initrd-root-fs.target
job 2) the emergency service gets stopped due to "systemctl isolate"
thereby throwing "Transaction is destructive".

In order to solve it, we can utilize "IgnoreOnIsolate=yes" for both
kdump-emergency.service and kdump-emergency.target. Unit with attribute
"IgnoreOnIsolate=yes" won't be stopped when isolating another unit,
they can keep going as expected in case be triggered by any failure.

We add kdump-emergency.target dedicated to kdump the similar way
as did for kdump-emergency.service(i.e. will replace systemd's
emergency.target with kdump-emergency.target under kdump), and
adds "IgnoreOnIsolate=yes" into both of them.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
[bhe: improve the patch log about IgnoreOnIsolate="]
2017-03-31 11:54:30 +08:00

15 lines
451 B
SYSTEMD

# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Emergency Mode
Documentation=man:systemd.special(7)
Requires=emergency.service
After=emergency.service
AllowIsolate=yes
IgnoreOnIsolate=yes