On 03/27/2017 at 07:33 PM, Baoquan He wrote:
On 03/27/17 at 07:18pm, Xunlei Pang wrote:
>>> Should be "to stop current running services" when "systemctl
isolate" is executed.
>>> For example, "dump_to_rootfs" will execute "systemctl start
dracut-initqueue", then
>> Seems no. Here we execute "systemctl start dracut-initqueue" just
>> because we can't use systemd service mechanism, the reaons is simple,
>> isolate is specified in kdump service.
>>
>> "systemctl start dracut-initqueue" is running command, like we start a
>> user space program, not by service starting way. My understanding.
> This is beyond my head, from my understanding "systemctl start
dracut-initqueue" should
> equal "systemctl start dracut-initqueue.service", just like "systemctl
start sysroot" equals
> "systemctl start sysroot.mount".
You are right. I regretted when I re-read it. But as you said, just dump
to root fs is executed in a isolate kdump emergency service, the new
service started by systemctl start dracut-initqueue won't be really
started by systemd. It's later new service relative to kdump emergency
service.
>> Hi Xunlei,
>>
>> I vaguely remember you are gonna to cleanup away dump to rootfs, then
>> maybe removing kdump error handler is a choice. Like Pratyush, making it
> I don't have such plan, which BZ# do you mean?
Never mind, could be I remember it wrongly.
>> 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?
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.
Regards,
Xunlei