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@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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
Thanks Dave