Description of problem: 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 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 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 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 Another app is currently holding the kdump lock; waiting for it to exit.. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
This 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 15th 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 These are the POSIX special builtins: break : . continue eval exec exit export readonly return set shift trap unset I suggest fixing the bug by checking exec return value.
Sorry it should be the 16th item.