[PATCH] kdump-lib.sh: fix incorrect usage with pipe as input for grep -q in is_pcs_fence_kdump()
For -q option, as man grep says: Exit immediately with zero status if any match is found, even if an error was detected. So when matching, the read side of pipe is closed by "grep -q", while the write side still try to write more data, which cause SIGPIPE to the process, and the shell can not exit with 0. It depends on the kernel's implementation of pipe to decide how much data written by the producer can trigger the bug.
Bash test script: #!/bin/sh set -o pipefail dd if=/dev/zero of=text.file bs=1M count=1 sed -i '1s/^/keyword /' text.file cat text.file | grep -q keyword echo $?
Notice the "set -o pipefail" is set by dracut, so mkdumprd -> dracut -> dracut-module-setup.sh -> is_pcs_fence_kdump() trigger the bug.
Signed-off-by: Pingfan Liu piliu@redhat.com --- kdump-lib.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index e3b5a01..8ebad70 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -63,7 +63,7 @@ is_pcs_fence_kdump() [ -x $FENCE_KDUMP_SEND ] || return 1
# fence kdump not configured? - (pcs cluster cib | grep -q 'type="fence_kdump"') &> /dev/null || return 1 + (pcs cluster cib | grep 'type="fence_kdump"') &> /dev/null || return 1 }
# Check if fence_kdump is configured using kdump options
On Friday 10 February 2017 07:50 AM, Pingfan Liu wrote:
For -q option, as man grep says: Exit immediately with zero status if any match is found, even if an error was detected. So when matching, the read side of pipe is closed by "grep -q", while the write side still try to write more data, which cause SIGPIPE to the process, and the shell can not exit with 0. It depends on the kernel's implementation of pipe to decide how much data written by the producer can trigger the bug.
Bash test script: #!/bin/sh set -o pipefail dd if=/dev/zero of=text.file bs=1M count=1 sed -i '1s/^/keyword /' text.file cat text.file | grep -q keyword echo $?
Notice the "set -o pipefail" is set by dracut, so mkdumprd -> dracut -> dracut-module-setup.sh -> is_pcs_fence_kdump() trigger the bug.
Signed-off-by: Pingfan Liu piliu@redhat.com
Acked-by: Pratyush Anand panand@redhat.com
kdump-lib.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index e3b5a01..8ebad70 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -63,7 +63,7 @@ is_pcs_fence_kdump() [ -x $FENCE_KDUMP_SEND ] || return 1
# fence kdump not configured?
- (pcs cluster cib | grep -q 'type="fence_kdump"') &> /dev/null || return 1
- (pcs cluster cib | grep 'type="fence_kdump"') &> /dev/null || return 1
}
# Check if fence_kdump is configured using kdump options
On 02/10/17 at 10:20am, Pingfan Liu wrote:
For -q option, as man grep says: Exit immediately with zero status if any match is found, even if an error was detected. So when matching, the read side of pipe is closed by "grep -q", while the write side still try to write more data, which cause SIGPIPE to the process, and the shell can not exit with 0. It depends on the kernel's implementation of pipe to decide how much data written by the producer can trigger the bug.
Bash test script: #!/bin/sh set -o pipefail dd if=/dev/zero of=text.file bs=1M count=1 sed -i '1s/^/keyword /' text.file cat text.file | grep -q keyword echo $?
Notice the "set -o pipefail" is set by dracut, so mkdumprd -> dracut -> dracut-module-setup.sh -> is_pcs_fence_kdump() trigger the bug.
Signed-off-by: Pingfan Liu piliu@redhat.com
kdump-lib.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index e3b5a01..8ebad70 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -63,7 +63,7 @@ is_pcs_fence_kdump() [ -x $FENCE_KDUMP_SEND ] || return 1
# fence kdump not configured?
- (pcs cluster cib | grep -q 'type="fence_kdump"') &> /dev/null || return 1
- (pcs cluster cib | grep 'type="fence_kdump"') &> /dev/null || return 1
}
# Check if fence_kdump is configured using kdump options
2.7.4
It looks good, thanks! Acked-by: Dave Young dyoung@redhat.com
Dave
On 02/10/17 at 10:20am, Pingfan Liu wrote:
For -q option, as man grep says: Exit immediately with zero status if any match is found, even if an error was detected. So when matching, the read side of pipe is closed by "grep -q", while the write side still try to write more data, which cause SIGPIPE to the process, and the shell can not exit with 0. It depends on the kernel's implementation of pipe to decide how much data written by the producer can trigger the bug.
Bash test script: #!/bin/sh set -o pipefail dd if=/dev/zero of=text.file bs=1M count=1 sed -i '1s/^/keyword /' text.file cat text.file | grep -q keyword echo $?
Notice the "set -o pipefail" is set by dracut, so mkdumprd -> dracut -> dracut-module-setup.sh -> is_pcs_fence_kdump() trigger the bug.
Signed-off-by: Pingfan Liu piliu@redhat.com
kdump-lib.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index e3b5a01..8ebad70 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -63,7 +63,7 @@ is_pcs_fence_kdump() [ -x $FENCE_KDUMP_SEND ] || return 1
# fence kdump not configured?
- (pcs cluster cib | grep -q 'type="fence_kdump"') &> /dev/null || return 1
- (pcs cluster cib | grep 'type="fence_kdump"') &> /dev/null || return 1
}
# Check if fence_kdump is configured using kdump options
2.7.4 _______________________________________________ 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
-
Dave Young -
Pingfan Liu -
Pratyush Anand