On Mon, Apr 26, 2021 at 12:01 PM Coiby Xu <coxu(a)redhat.com> wrote:
On Mon, Apr 26, 2021 at 11:51:07AM +0800, Coiby Xu wrote:
>On Sun, Apr 25, 2021 at 04:36:31PM +0800, Kairui Song wrote:
>>Thanks! You are right, in such case dracut-initqueue will stuck in
>>"activating" status, I think maybe the only way to check if the
>>service is check with "systemctl status", will update the patch.
>>
>
>You are welcome! It seems this is the intended behaviour of
>dracut-intique that it succeeds when there is script inside
>"$hookdir/initqueue/finished" that never return true. A systemd
>service
>succeeds when exit code status is 0. Since
>modules.d/98dracut-systemd/dracut-initqueue.sh could deal with this
>case
>and exit with code 0, "systemctl is-failed" is false.
But I don't understand why the dracut-initque can't deal with this case
the second time it's started and stuck in "activating" status.
I guess it's just kdump emergency handler got stuck, as it try to call
'systemctl start dracut-initqueue', but 'dracut-initqueue' is stuck in
'activating' status waiting for the kdump emergency handler
(emergency_shell call in initqueue will just call ). So this created a
dead loop. Which is exactly what commit 002337c tried to avoid but I
reverted it in later patches as I thought "is-active || is-failure"
can detect such case.
So the solution here could be check dracut-initqueue status, and try
start it only if it's in 'inactive' status.
--
Best Regards,
Kairui Song