On 03/28/2017 at 03:26 PM, Baoquan He wrote:
On 03/28/17 at 09:28am, Xunlei Pang wrote:
> On 03/28/2017 at 09:03 AM, Baoquan He wrote:
>>> This is the biggest advantage of WANG Chao 's design, I can't think
of a better way
>>> currently except adding hooks in dracut for kdump, any good idea?
>> Seems no better way to do this. Both dracut and systemd make emergency
>> reaction as entering into emergency shell. While kdump customers want
>> the action as the one they specified in "default xxx" in
>> /etc/kdump.conf. Otherwise we have to embed our special handling code
>> into dracut, this is what I ever did. But that is too ugly and has been
>> removed.
> Yes, agree.
>
>> And isolate is to break the loop which default action specified as
>> dump_to_rootfs may cause.
> I personally like replacing "isolate" with "start" as well, as
it's simple and straightforward.
>
> Maybe we could eliminate the "dump_to_rootfs" loop issue by replacing
dump_to_rootfs'
> "systemctl start dracut-initqueue" with calling "/bin/initqueue"
directly?
I am not sure if that is OK. In service some env variables are set.
Maybe a test can be take to check.
> But except that, there are two other known problems I've met if using
"start" instead:
> 1) In case of failure, kdump-capture.service will still be started by initrd.target,
> finally we will trigger kdump emergency shell twice.
> 2) Some systemd services are not stopped like before, i.e. we will have more
services
> running with kdump error handler service.
>
> If the above-mentioned problems(and potential concerns) can be correctly
resolved/accepted,
> I think we can do it.
Yes, agree. So then for the time bing we can leave it as is, do not
pursuit non-isolate service. If later have a good chance, can make it.
Ok, I have no objection on this, thanks for review.
Regards,
Xunlei