On Fri, Jul 25, 2014 at 01:44:40PM +0800, WANG Chao wrote:
On 07/24/14 at 01:35pm, Vivek Goyal wrote:
> On Fri, Jul 25, 2014 at 12:13:45AM +0800, WANG Chao wrote:
> > Now when mount in /etc/fstab fails, systemd would not consider it as
> > critical and it would continue to boot. In fact, emergency service is
> > triggered, but not in a isolation mode, and it results in the emergency
> > service getting shutdown at some point later of the boot process. We
> > need isolation otherwise we won't see any emergency service.
> >
> > That is because in kdump initramfs, mount units specified in /etc/fstab
> > are required by "local-fs.target". When any of these mounts fails,
> > local-fs.target fails.
> >
> > For kdump initramfs, we need to isolate to emergency service on any of
> > the mount failure, that said, every service should be stopped and onlu
> > emergency service would run. But local-fs.target won't trigger that on
> > its failure. That means in case of mount failure, local-fs.target also
> > enters failure state, but all the service will continue without any
> > interruption.
> >
> > After digging looking into source code of systemd-fstab-generator. I
> > find "x-initrd.mount" using in initramfs mount, will make the mount
> > units required by "initrd-root-fs.target" rather than it's used
to be
> > "local-fs.target".
> >
> > "initrd-root-fs.target" is suitable to us because if it fails, it
will
> > isolate to emergency service. That means in case of any mount failure,
> > the emergeny service will start and everything else will stop. We want
> > this effect because we need to take kdump fail-safe action when there's
> > a mount failure.
> >
> > >From systemd unit point of view, "initrd-root-fs.target" has
> > OnFailureIsolate=yes, but "local-fs.target" doesn't. From
> > systemd.unit(5):
> >
> > OnFailureIsolate=
> > Takes a boolean argument. If true, the unit listed in OnFailure=
> > will be enqueued in isolation mode, i.e. all units that are not its
> > dependency will be stopped. If this is set, only a single unit may
> > be listed in OnFailure=. Defaults to false.
> >
> > NOTE: Harald who contributed "x-initrd.mount" in systemd, confirmed
that
> > this feature will stay.
> >
> > Signed-off-by: WANG Chao <chaowang(a)redhat.com>
> > ---
> > mkdumprd | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/mkdumprd b/mkdumprd
> > index ba35800..9ee2f0b 100644
> > --- a/mkdumprd
> > +++ b/mkdumprd
> > @@ -106,6 +106,12 @@ to_mount() {
> > _fstype=$(findmnt -k -f -n -r -o FSTYPE $_dev)
> > _options=$(findmnt -k -f -n -r -o OPTIONS $_dev)
> > _options=${_options/#ro/rw} #mount fs target as rw in 2nd kernel
> > + # "x-initrd.mount" mount failure will trigger isolate emergency
service
> > + # W/o this, systemd won't isolate, thus we won't get to emergency
> > + # This only applicable for local fs mount
> > + if ! is_nfs_target; then
> > + _options="$_options,x-initrd.mount"
> > + fi
>
> So why is it applicable to local fs mounts only. What will happen in
> case of remote mount. Do we already isolate to emergency service in that
> case?
If we use "x-initrd.mount", remote mount will become required by
"initrd-root-fs.target", instead of "remote-fs.target". That's
how it is
handled within systemd internal.
We need remote mount to be required "remote-fs.target", because we need
to bring up network before any remote mount and "remote-fs.target" can
be a checkpoint of that.
So first of all this explanation should be part of the comment near the
code.
Secondly, so what will happen if nfs mount fails and remote-fs.target
does not reach. Will we isolate to kdump error handler or not? So handling
of remote-fs.target is different from local-fs.target when it comes
to emergency shell? I think all this needs to be part of changelog/comment
so that reader can understand why are we treating remote mounts and
local mounts differently.
>
> Also what happens in case of raw disk? What happens in case of ssh dump
> when network interface does not show up?
In dracut-initqueue hook, both network and disk will be brought up, if
needed. And kdump.sh runs after dracut-initqueue, so network and disk
will be there before running kdump.sh.
So if dracut-initqueue fails/timesout, will we isolate to kdump emergency
shell?
Thanks
Vivek