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.
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.
Thanks
WANG Chao