On 03/27/2017 at 04:25 PM, Dave Young wrote:
On 03/27/17 at 04:03pm, Xunlei Pang wrote:
> On 03/27/2017 at 03:40 PM, Pratyush Anand wrote:
>> Hi Xunlei,
>>
>> On Monday 27 March 2017 09:37 AM, Xunlei Pang wrote:
>>> 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).
>> I could not understand why kdump emergency.service needs isolate while, it is not
needed in first kernel (ie in systemd). If kdump would work without isolate then probably
it will be more closer to upstream systemd and we will need less modifications in kdump.
> Yes, what you said is another solution.
>
> Seems Dave has some concern about we may not stop some services like before if
replacing "isolate" with "start".
> From my tests it is true that some services will be continuing.
>
> Hi Dave, what is you opinion?
I do not remember why we use isolate previously. I thought it is for
force run kdump error handler service so that kdump error handler ensure
not to be blocked by other services.
Suppose other service can run in an infinite loop, does the "start"
still work for us? For example we expect "default shell" but other
services runs in a loop or something else..
It may be due to our "default XXX" feature, we have to ensure it executes
reliably as possible as it can in case of emergency.
In my view, we have been using "isolate" since 2014, better no touch that,
that's why after some thinking I choose this method.
Regards,
Xunlei