On Fri, May 09, 2014 at 04:25:13PM +0800, WANG Chao wrote:
On 05/08/14 at 12:07pm, Vivek Goyal wrote:
> On Thu, May 08, 2014 at 08:30:19PM +0800, WANG Chao wrote:
>
> [..]
> > Because when emergency.service is triggered, all the other services are
> > stopped running, even the mounted filesystem is umounted.
>
> This is strange. Why already mounted filesysems should be unmounted. I
> think we should send a mail to systemd and ask about this behavior.
I think that a mount unit is just like a service unit from systemd's
point of view. When systemd "isolate" to emergency.target, all the rest
of units (including service/target/mount/slice/... man systemd.unit(5)
for more types) will be stopped.
What does it mean to stop a "target" unit? That means target will be
considered not reached?
"isolate" is targeting all unit types, not just for xxx.service.
FWIW one can specify "IgnoreOnIsolate=yes" to any type of unit to avoid
being stopped. But this is not our case, because mount units are
generated runtime.
>
> >
> > But I've figured a way to bring /sysroot back to life before
> > dump_to_rootfs by manually:
> >
> > systemctl start initqueue
s/initqueue/dracut-initqueue
> > systemctl start sysroot.mount
>
> I am not convinced with this idea of trying to call back into systemd
> to start some units after failure. This sounds little fragile to me.
dracut-initqueue only have dependencies for udev related unit. In fact,
it will only run the scripts under initqueue hook (like dracut-pre-pivot
hook). The initqueue hook is used to bring device online by some
installed scripts at generate-time.
It looks to me both dracut-initqueue.service and sysroot.mount are
pretty much independant. So I think that would be too much risky to call
back to these two.
>
> Having said that, it might not be perfect solution but if it works, it
> might not be too bad a solution till we find even better solution.
Bottom line is we need /sysroot when dump_to_rootfs ...
>
> Do we really have to kick initqueue again? Just starging sysroot.mount
> is not enough?
Probally not "again". Failure can happen at any point of time, that
means it could happen before dracut-initqueue gets started. So starting
dracut-initqueue will ensure that the desired device is brought up
before trying to mount it. Otherwise starting sysroot.mount will be
blocking to wait for the disk.
>
> Also after starting sysroot.mount, how long will you wait for root to
> be mounted?
"systemctl start sysroot.mount" will block as long as it's mounted or
the worst case timeout after 90 seconds.
If everything goes smoothly, sysroot.mount shouldn't block for long.
Interesting. What decides when do we wait for systemctl command and
when we just send a message to systemd on dbus and exit.
>
> How are you inducing failure to invoke this error path?
There's a critical path for systemd boot (man bootup(7)).
This is a very good writeup. Good find.
Ok, I have couple of more questions.
As per bootup(7), basic.target should be reached first. I checked that
there is no OnFailure= directive in basic.target. So say some error
happens and basic.target does not reach. What happens now? Will system
hang?
Second quesiton, So looks like there are two error paths. If error
happens early enough, then dracut can drop us into emergency shell
otherwise later systemd can put us into emergency shell. It depends
when error happened.
If error happened in dracut early, then tyring to kick dracut initqueue
again will most likely not help much. If error happens later in systemd
when it is trying to mount non-root file systems, then kicking
dracut-initqueue and enabling sysroot.mount might help.
BTW, I still don't understand that why should we try to enable
dracut-initqueue explicitly. If sysroot.mount depends on it, then it
will automatically be enabled.
Secondly, if error happened before dracut-initqueue, then there is
no point in running initqueue scripts. If error happend after dracut
initqueue, then none of the initqueue action will be undone and there
is no need to run dracut-initqueue.
So I think we just need to explicitly enable sysroot.mount from kdump
handler. If it blocks for 90 seconds, we don't have to do anything. But
if it exits immediately, then we need to sit in a tight loop and wait
for 90 seconds. If root shows up, dump to it otherwise reboot.
Thanks
Vivek