On Sat, Aug 02, 2014 at 12:14:16AM +0800, WANG Chao wrote:
On 08/01/14 at 08:39am, Vivek Goyal wrote:
> On Fri, Aug 01, 2014 at 01:04:54PM +0800, WANG Chao wrote:
>
> [..]
> > dracut-initqueue is a special case, which calls "systemctl start
> > emergency" directly, not via "OnFailure=emergency". In case of
failure,
> > emergency is started, but not in a isolation mode, which means
> > dracut-initqueue is still running. On the other hand, emergency will
> > call 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. It looks like the following:
> >
> > dracut-initqueue (running)
> > --> call dracut-emergency:
> > --> dracut-emergency (running)
> > --> kdump-error-handler.sh (running)
> > --> call dracut-initqueue:
> > --> blocking and waiting for the original instance to exit.
> >
> > To fix this, I'd like to introduce a wrapper emergency service. This
> > emegency service will replace both the systemd and dracut emergency. And
> > this service does nothing but to isolate to real kdump error handler
> > service:
> >
> > dracut-initqueue (running)
> > --> call dracut-emergency:
> > --> dracut-emergency isolate to kdump-error-handler.service
> > --> dracut-emergency and dracut-initqueue will both be stopped
> > and kdump-error-handler.service will run kdump-error-handler.sh.
> >
>
> Chao,
>
> So how does it now work in case of recursion.
>
> I mean say dracut-initqueue failed. We got into kdump-error-hanlder.sh.
> Which in turn called dracut-initqueue again and it will fail again.
>
> Now dracut-initqueue will call dracut-emergency and dracut-emergency
> will try to isolate to kdump-error-handler.service. Will it now block
> because kdump-error-handler is already running or it will stop existing
> running instance of kdump error handler.
dracut-emergency will run:
systemctl --no-block isolate kdump-error-handler.service
"--no-block" will means do not block, return rigth away.
So in your case, when kdump-error-handler is running and the second time
dracut-initqueue fails, dracut-emergency will try to isolate to
kdump-error-handler in a non-block mode and return immediately. And then
the second dracut-initqueue will return and kdump-error-handler.sh will
continue its code flow.
Ok, thanks for the explanation. This kdump error handling with dracut
and systemd is turning out to be very complicated.
Thanks
Vivek