Bug#19920049 - MYSQLD_MULTI MISLEADING WHEN MY_PRINT_DEFAULTS
IS NOT FOUND DESCRIPTION =========== If script mysqld_multi and utility my_print_defaults are in the same folder (not included in $PATH) and the former is made to run, it complaints that the mysqld binary is absent eventhough the binary exists. ANALYSIS ======== We've a subroutine my_which() mimicking the behaviour of POSIX "which" command. Its current behaviour is to check for a given argument as follows: - Step 1: Assume the argument to be a command having full fledged absolute path. If it exists "as-is", return the argument (which will be pathname), else proceed to Step 2. - Step 2: Assume the argument to be a plain command with no aboslute path. Try locating it in all of the paths (mentioned in $PATH) one by one. If found return the pathname. If found nowhere, return NULL. Currently when my_which(my_print_defaults) is called, it returns from Step 1 (since utlity exists in current folder) and doesn't proceed to Step 2. This is wrong since the returned value is same as the argument i.e. 'my_print_default' which defies the purpose of this subroutine whose job is to return a pathname either in Step 1 or Step 2. Later when the utility is executed in subroutine defaults_for_group(), it evaluates to NULL and returns the same. This is because the plain command 'my_print_defaults {options} ...' would execute properly only if my_print_defaults exists in one of the paths (in $PATH). In such a case, in the course of the flow it looks onto the variable $mysqld_found which comes out to be NULL and hence ethe error. In this case, call to my_which should fail resulting in script being aborted and thus avoiding this mess. FIX === This utility my_print_defaults should be tested only in Step 2 since it does not have an absolute path. Thus added a condition in Step 1 so that is gets executed iff not called for my_print_defaults thus bypassing it to proceed to Step 2 where the check is made for various paths (in $PATH)
Showing
Please register or sign in to comment