3578c54ff2
1 Commits
Author | SHA1 | Message | Date | |
---|---|---|---|---|
|
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="] |