On Tue, Apr 06, 2021 at 01:33:05PM +0800, Kairui Song wrote:
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.
Then you seem to have made a mistake in "[PATCH 1/3] Don's try
to restart dracut-initqueue if it's already there" because it will
start initqueue when is-failed return true,
+ if ! systemctl is-active dracut-initqueue || systemctl is-failed dracut-initqueue;
then
+ dinfo "Trying to bring up initqueue for rootfs mount"
+ systemctl start dracut-initqueue
+ fi
+
--
Best Regards,
Kairui Song
--
Best regards,
Coiby