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.
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
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.
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
Acked-by: Dave Young dyoung@redhat.com
Thanks Dave
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:
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.
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
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
On 07/31/2017 at 09:48 PM, 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:
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) """"""
There will be a systemd message to tip users about the progress like below, so I think it is fine:
[*** ] (1 of 1) A start job is running for... (31s / 5min)
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.
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
On 07/31/2017 at 06:17 PM, 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.
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"
BTW, I've tested nfs mount, seems no side effect to add this option for it, but I think we better not do it for nfs.
Another issue is that when testing root mount(/sysroot), this timeout option doesn't seems to work, so I think we can change all kinds of mount under kdump to use /kdumproot/?
Maybe I can send v3. @Dave, what do you think?
Regards, Xunlei
- fi
- _mntopts="$_target $_fstype $_options" #for non-nfs _dev converting to use udev persistent name if [ -b "$_source" ]; then
On 08/01/2017 at 09:38 AM, Xunlei Pang wrote:
On 07/31/2017 at 06:17 PM, 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.
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"BTW, I've tested nfs mount, seems no side effect to add this option for it, but I think we better not do it for nfs.
I am planning to do this by adding a new /etc/systemd/system.conf.d/kdump.conf under kdump, so this will be solved naturally.
Another issue is that when testing root mount(/sysroot), this timeout option doesn't seems to work, so I think we can change all kinds of mount under kdump to use /kdumproot/?
After coding for a while, I found that we have to handle fadump separately which makes the code uglier, given that we only met such issues on non-root targets, so I preferred not handling it currently.
Regards, Xunlei
Maybe I can send v3. @Dave, what do you think?
Regards, Xunlei
- fi
- _mntopts="$_target $_fstype $_options" #for non-nfs _dev converting to use udev persistent name if [ -b "$_source" ]; then
-
Baoquan He -
Dave Young -
Xunlei Pang -
Xunlei Pang