On 05/13/14 at 08:53am, Vivek Goyal wrote:
On Tue, May 13, 2014 at 01:46:29PM +0800, WANG Chao wrote:
> Hi, Vivek
>
> As we discussed at the meeting yesterday, you brought up the idea about
> making emergency.service to "Wants=" and "After="
> dracut-iniqueue.service and sysroot.mount.
>
> I tested it today and it worked well. And then I realize why I didn't
> do that before. I don't think that's a good idea.
>
> Because we have several default actions and only dump_to_rootfs would
> require sysroot.mount. Like you said, start dracut-initqueue and
> sysroot.mount might be fragile in a broken systemd boot. If we do that
> unconditionally for all the default actions, we might be broken again.
>
> So I'm thinking how about we write a generator to add these dependencies
> on the fly according to default actions specified in kdump.conf. With
> the dependencies, the stop/start cycle of initqueue and sysroot.mount
> can be avoided because systemd would do the isolation without stopping
> these two.
Hi Chao,
I think relying on a service has the fundamental problem that this service
might never be started.
It goes back to same issue that errors from .target units is not
propagated upwards. If some target is not reached and if sysroot.mount
and dracut-initqueue services are dependent on that target, then these
services will never be started.
That means kdump error handler service will never be started and we will
be hung? And that's the precise problem we are trying to solve.
You're right. That could cause emergency.service never got started if
its dependencies are failed. So we can only manually start
dracut-initqueue.service and sysroot.mount within our error handler.
So to me we need to fix this error propagation behavior first before we
can install a kdump error handler service.
Starting sysroot.mount from kdump handler and polling for root to mount
has the advantage that we can timeout and reboot after some time.
Right, let's stick to this.
Thanks
WANG Chao