On Tue, Apr 6, 2021 at 4:20 PM Coiby Xu <coxu(a)redhat.com> wrote:
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
+
Ah, yes, I missed a bracket, it should be:
if ! ( systemctl is-active dracut-initqueue || systemctl is-failed
dracut-initqueue ); then
Let me update the patch.
--
Best Regards,
Kairui Song