Hi Baoquan,
On 07/31/17 at 09:48pm, Baoquan He wrote:
On 07/31/17 at 06:17pm, Xunlei Pang wrote:
> Currently, systemd uses 90s as the default mount unit timeout,
> in some cases, although it works well in 1st kernel, it's not
> enough under kdump and results in mount timeout, further results
> in kdump dumping failure.
>
> We've met several such issues, we decided to enlarge this default
> value a little for kdump.
>
> We finalize "x-systemd.device-timeout=300" as the default timeout
> to the mount options if there is no "x-systemd.device-timeout=X"
> specified. It can be overridden by /etc/fstab mount options,etc,
> so that users can specify other timeout values if they want to.
>
> Note: this is different from rd.timeout which was introduced by
> dracut initqueue.
>
> Signed-off-by: Xunlei Pang <xlpang(a)redhat.com>
> ---
> v1->v2:
> -Use 300s other than 600s as the default value.
I am sorry, I am still wondering why we can't add a new option in
kdump.conf, or a simply knob in kdump.conf to let them to turn on to
enable 600s default value, otherwise 90s default value. But not simply
increase the default value. It's 5 minute. Here comes an example:
It is not worth to add a new option to maintain it always if this just
work. Xunlei proposed to reuse rd.timeout but that has a little
different purpose and we still need maintain it in kdump. It is better
to let user add their own values in fstab, or modify the systemd config
files.
https://bugzilla.redhat.com/show_bug.cgi?id=1419613
"""""
Then on console system hang at the following message (I waited for about
5 minutes and there is no updates)
""""""
You can see the QE contact, Ziqian said she/he waited for about 5
minutes to make sure it's hang. So increasing to 300s can't solve the
problem reported that large system need wait 10 minutes to mount, and
drag all failure cases of normal system to 5 minutes to wait, what's the
point of increasing it to 300s? You can see, even on my hp z420 work
station, mounting only costs tens of seconds.
5 minutes sounds too agressive to think the machine hangs, AFAIK nfs
mount timeout can be 600s. I think QE should tune their test cases for
this.
Since systemd has some messages it is likely to judge it is a user space
"hang" instead of a kernel hang from the console messages also..
Just my personal opinion to this 300s, no any offence.
Thanks
Baoquan
>
> mkdumprd | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/mkdumprd b/mkdumprd
> index d3ecbd6..29e51a9 100644
> --- a/mkdumprd
> +++ b/mkdumprd
> @@ -104,6 +104,12 @@ to_mount() {
> _options=$(echo $_options | sed 's/noauto//')
> _options=${_options/#ro/rw} #mount fs target as rw in 2nd kernel
>
> + # kdump turns out to require longer default systemd mount timeout
> + # than 1st kernel(90s by default), we choose 300s for kdump.
> + if ! strstr $_options "x-systemd.device-timeout"; then
> + _options="$_options,x-systemd.device-timeout=300"
> + fi
> +
> _mntopts="$_target $_fstype $_options"
> #for non-nfs _dev converting to use udev persistent name
> if [ -b "$_source" ]; then
> --
> 1.8.3.1
> _______________________________________________
> kexec mailing list -- kexec(a)lists.fedoraproject.org
> To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org
_______________________________________________
kexec mailing list -- kexec(a)lists.fedoraproject.org
To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org
Thanks
Dave