Description of problem
(
https://bugzilla.redhat.com/show_bug.cgi?id=1465735):
Run `kdumpctl status` as normal user, get below error messages:
Another app is currently holding the kdump lock; waiting for it to exit...
flock: 9: Bad file descriptor
Another app is currently holding the kdump lock; waiting for it to exit...
flock: 9: Bad file descriptor
...
The bug is caused by behavior difference between bash
and sh (bash in posix).
In the function single_instance_lock in kdumpctl script,
there is
exec 9>/var/lock/kdump
which will fail in user mode. However, this fail will cause
script exit under bash and non-exit under sh, causing infinite
loop because the flock will always fail.
According to the 16th item in
ftp://ftp.gnu.org/old-gnu/Manuals/bash-2.02/html_node/bashref_66.html
If a POSIX.2 special builtin returns an error status, a non-
interactive shell exits.
And according to
https://www.gnu.org/software/bash/manual/html_node/Special-Builtins.html
exec is one of the POSIX.2 special builtin's.
This patch fixes the bug by checking exec return value.
Signed-off-by: Ziyue Yang <ziyang(a)redhat.com>
---
kdumpctl | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/kdumpctl b/kdumpctl
index e440bbb..a517925 100755
--- a/kdumpctl
+++ b/kdumpctl
@@ -37,6 +37,10 @@ single_instance_lock()
local rc timeout=5
exec 9>/var/lock/kdump
+ if [ $? -ne 0 ]; then
+ echo "Creating file lock failed"
+ exit 1
+ fi
flock -n 9
rc=$?
--
2.9.3