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@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=$?