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