On 03/27/17 at 04:38pm, Xunlei Pang wrote:
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.
It looks good, I think isolate is just right and make sense.
Ack this patch.
Thanks
Dave