On 03/27/17 at 08:44pm, Xunlei Pang wrote:
On 03/27/2017 at 07:33 PM, Baoquan He wrote:
>>> be consistent with dracut/systemd behaviour is better for our code
>>> maintaining. Personnal opinion.
>> Currently using "start" instead of "isolate" is problematic,
we have to discuss further and
>> figure out a new way if wanting to be align with systemd/dracut behaviour.
> Yeah, if we can, that surely is better.
>
Reading more code, and return here I'd like to throw out some personal view as well:
There is one key issue that commit 002337c67 ("Introduce kdump error handling
service")
tries to address besides "the initqueue issue", as the changelog says:
"By default systemd provides an emergency service which will drop us into
shell every time upon a critical failure. It's very convenient for us to
re-use the framework of systemd emergency, because we don't have to
touch the other parts of systemd. We can use our own script instead of
the default one.
This new scheme will overwrite emergency shell and replace with kdump
error handling code. And this code will do the error handling as needed.
Now, we will not rely on dracut-pre-pivot hook running always. Instead
whenever error happens and it is serious enough that emergency shell
needed to run, now kdump error handler will run.
dracut-emergency is also replaced by kdump error handler and it's
enabled again all the way down. So all the failure (including systemd
and dracut) in 2nd kernel could be captured, and trigger kdump error
handler."
Now if any error happens at any systemd/dracut boot stage, we can trigger kdump
error handler with the help of replacing systemd/dracut emergency services in WANG
Chao's patch(i.e. commit 002337c67).
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.
And isolate is to break the loop which default action specified as
dump_to_rootfs may cause.
So seems the current way is the best way we can do.
On the other hand, there is also one "isolate" example in
"98systemd/emergency.service":
"ExecStopPost=-/usr/bin/systemctl --no-block isolate default.target"
although it is for "ExecStopPost=", not sure if we use "isolate" in
kdump emergency service
will be regarded as not align with systemd/dracut behaviour.
We just try our best to align with upstream behaviour. If have to not,
then we can accept. I think whatever it is, it's worth making it clear.
Now I believe we all know what and why those are, can adjust anytime
when necessary.
Thanks
Baoquan