In the sqm-scripts package for managing network traffic shaping is this line for finding a program suitable for loading the kernel shaping modules:
[ -z "$INSMOD" ] && INSMOD=$(which modprobe) || INSMOD=$(which insmod)
It seems to set INSMOD to /usr/sbin/insmod, even though /usr/sbin/modprobe is available. (Both are symlinks to ../bin/kmod.)
According to this article, the return value of the first assignment should be success and it shouldn't take the fallback statement:
Also working the issue here:
I think this is a problem with the precedence of && vs ||. If INSMOD is not set, it will work as you intend, but once it's set, only the || branch will execute.
You can fix it if you group the assignments together:
[ -z "$INSMOD" ] && (INSMOD=$(which modprobe) || INSMOD="$(which insmod)")
On Sat, Feb 27, 2021 at 01:32:55PM -0800, Kenneth Porter wrote:
In the sqm-scripts package for managing network traffic shaping is this line for finding a program suitable for loading the kernel shaping modules:
[ -z "$INSMOD" ] && INSMOD=$(which modprobe) || INSMOD=$(which insmod)
It seems to set INSMOD to /usr/sbin/insmod, even though /usr/sbin/modprobe is available. (Both are symlinks to ../bin/kmod.)
According to this article, the return value of the first assignment should be success and it shouldn't take the fallback statement:
Also working the issue here:
https://github.com/tohojo/sqm-scripts/issues/133
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 2/27/21 1:32 PM, Kenneth Porter wrote:
[ -z "$INSMOD" ] && INSMOD=$(which modprobe) || INSMOD=$(which insmod)
It seems to set INSMOD to /usr/sbin/insmod, even though /usr/sbin/modprobe is available. (Both are symlinks to ../bin/kmod.)
[ -z "$INSMOD" ] && INSMOD=$(which modprobe) || INSMOD=$(which insmod)
This should be re-written as:
[ -z "$INSMOD" ] && { INSMOD=$(which modprobe) || INSMOD=$(which insmod) ; }
As it is currently written, if INSMOD is set previously, it will be replaced with the output of "which insmod". That is, the final statement will be evaluated if either INSMOD was set previously, or if "which modprobe" exits with a non-zero status.
It's unlikely that this is a PATH issue since both modprobe and insmod are in the same directory. The most likely explanation is that $INSMOD had a value before that line was evaluated.
On 2/27/21 4:39 PM, Skylar Thompson wrote:
You can fix it if you group the assignments together: [ -z "$INSMOD" ] && (INSMOD=$(which modprobe) || INSMOD="$(which insmod)")
They do need to be grouped, but if you group them with parentheses, they execute in a subshell, and the assignment is lost. They should be grouped with braces instead.
-
Gordon Messmer -
Kenneth Porter -
Skylar Thompson