On Mon, Apr 26, 2021 at 03:53:56PM +0800, Kairui Song wrote:
On Mon, Apr 26, 2021 at 12:01 PM Coiby Xu coxu@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.
Yes, you are correct. I thought would exit with exit code 0 because I didn't notice dracut-initque would call emergency_shell,
if [ $main_loop -gt $RDRETRY ]; then if ! [ -f /sysroot/etc/fstab ] || ! [ -e /sysroot/sbin/init ]; then emergency_shell "Could not boot." fi
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