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.