O n Tue, Apr 6, 2021 at 10:08 AM Coiby Xu <coxu(a)redhat.com> wrote:
On Tue, Apr 06, 2021 at 09:38:53AM +0800, Kairui Song wrote:
>On Tue, Apr 6, 2021 at 7:46 AM Coiby Xu <coxu(a)redhat.com> wrote:
>>
>> On Fri, Apr 02, 2021 at 05:27:26PM +0800, Kairui Song wrote:
>> >On Fri, Apr 2, 2021 at 5:15 PM Coiby Xu <coxu(a)redhat.com> wrote:
>> >>
>> >> On Fri, Apr 02, 2021 at 04:03:36PM +0800, Kairui Song wrote:
>> >> >On Fri, Apr 2, 2021 at 12:28 PM Coiby Xu <coxu(a)redhat.com>
wrote:
>> >> >>
>> >> >> On Thu, Mar 18, 2021 at 01:12:30PM +0800, Kairui Song wrote:
>> >> >> >The wrapper is introduced in commit 002337c, according to
the commit
>> >> >> >message, the only usage of the wrapper is when
dracut-initqueue calls
>> >> >> >"systemctl start emergency" directly. In that
case, emergency
>> >> >> >is started, but not in a isolation mode, which means
dracut-initqueue
>> >> >> >is still running. On the other hand, emergency will call
>> >> >> >"systemctl start dracut-initqueue" again when
default action is dump_to_rootfs.
>> >> >> >
>> >> >> >systemd would block on the last dracut-initqueue, waiting
for the first
>> >> >> >instance to exit, which leaves us hang.
>> >> >> >
>> >> >> >In previous commit we added initqueue status detect in
dump_to_rootfs,
>> >> >> >so now even without the wrapper, it will not hang.
>> >> >> >
>> >> >> >And actually, previously, with the wrapper, emergency
might still hang
>> >> >> >for like 30s. When dracut called emergency service because
initqueue
>> >> >> >timed out, dump_to_rootfs will try start initqueue again
and timeout
>> >> >> >again. Now with the wrapper removed, we can avoid these
two kinds of
>> >> >> >hangs, bacause without the isolation we can detect
initqueue service
>> >> >> >status correctly in such case.
>> >> >> >
>> >> >>
>> >> >> I'm curious why should we start dracut-initqueue again in
>> >> >> dump_to_rootfs? When failure_action=dump_to_rootfs and I
comment out
>> >> >> "systemctl start dracut-initqueue", kdump works
fine. And if
>> >> >> dracut-iniqueue timed out before (e.g. because the dump target
is nfs
>> >> >> and there's no response from nfs server), won't
dracut-initque time out
>> >> >> again if we start it?
>> >> >>
>> >> >
>> >> >Hi Coiby,
>> >> >
>> >> >It depends on how kdump failed, and how rootfs is structured.
>> >> >
>> >> >If kdump failed before starting initqueue, then it might be
necessary
>> >> >to start initqueue.
>> >> >
>> >>
>> >> Thanks for the explaining! But doesn't
dracut-kdump-capture.service
>> >> start after dracut-initqueue.service?
>> >>
>> >> [Unit]
>> >> Description=Kdump Vmcore Save Service
>> >> After=initrd.target initrd-parse-etc.service sysroot.mount
>> >> After=dracut-initqueue.service dracut-pre-mount.service
dracut-mount.service dracut-pre-pivot.service
>> >>
>> >
>> >Yes, but the kdump initramfs may jump to emergency.target direct if
>> >some service failed, that will start our emergency helper direct, no
>> >matter which stage the kdump capture environment is currently at.
>> >
>> >> >The initqueue is responsible for a lot of things. eg. setup lvm
>> >> >mappers. If the rootfs is a partition on lvm, we will have to
setup
>> >> >lvm mappers first, so we need to ensure the initqueue is started.
If
>> >> >the initqueue haven't started yet, kdump can't find the
rootfs.
>> >> >
>> >>
>> >> I don't know much about systemd and sysroot.mount. In
dump_to_rootfs,
>> >> "systemctl start sysroot.mount" is called before dumping
vmcore? Does it
>> >> imply setting up lvm mappers will be took proper care because
sysroot.mount
>> >> depends on it?
>> >
>> >Yes, sysroot.mount will start after initqueue, and that should be
>> >enough. initqueue will setup all extra requirements for sysroot.mount
>> >
>>
>> I thought sysroot.mount is started through systemd in
>> dracut-kdump-emergency.service and systemd will automatically start the
>> services dependent by sysroot.mount. So somehow systemd can't do that and
>> only initqueue can setup all extra requirements?
>>
>> --
>> Best regards,
>> Coiby
>>
>
>It depends on the kind of dependency. Still for example, LVM mappers
>are too complex to be handled by systemd so it need initqueue to
>setup, and simple service dependency can be handled by systems. And
>sysroot.mount is a service created by systemd generator so it may miss
>some service dependency info.
>
Got it, thanks!
I have another question. If we restart failed dracut-initqueue.service in
dracut-kdump-emergency.service, it could fail gain. Would it restart
dracut-initque.service again thus lead to an infinite loop?
Yes, so we have introduced a status check in previous commit, will
skip initqueue service if "is-failed" or "is-active" return true.
--
Best Regards,
Kairui Song