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.