You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
MySQL core functionality uses variable PLESK_FILE to identify Plesk servers, and based on that will use the content of that file as the password when logging in as the MySQL admin user. E.g. in /usr/lib/recap/core/mysql:
...
local PLESK_FILE="/etc/psa/.psa.shadow"
if [[ -r "${PLESK_FILE}" ]]; then
echo "MySQL (plesk) status" >> "${LOGFILE}"
mysqladmin
-uadmin
-p$(cat "${PLESK_FILE}")
--connect-timeout=5
...
However, the variable is set as local and only in the functions print_mysql print_mysql_procs. This means function print_mysql_innodb_status doesn't have access to the variable, which results in it trying to use the MYCNF variable method to access MySQL, and fails unless the .my.cnf contains the correct credentials. And if the credentials are not correct then the InnoDB engine status is not logged.
The expected behaviour should be for function print_mysql_innodb_status to use the PLESK_FILE method on Plesk servers, but as the PLESK_FILE is not set globally, and not set locally within the function, it doesn't do so. It looks like the correct way to address this would either be to set PLESK_FILE as a global variable, or set it locally in the print_mysql_innodb_status function. Currently the function starts as:
...
print_mysql_innodb_status() {
log INFO "Starting 'mysql innodb' report - ${LOGFILE##*/}"
local LOGFILE="$1"
local MYCNF="$2"
local mysql_cmd=''
unset MYVALS PID_FILE TMPDIR
if [[ -r "${PLESK_FILE}" ]]; then
...
The suggestion is to set the PLESK_FILE variable locally:
...
print_mysql_innodb_status() {
log INFO "Starting 'mysql innodb' report - ${LOGFILE##*/}"
local LOGFILE="$1"
local MYCNF="$2"
local mysql_cmd='' local PLESK_FILE="/etc/psa/.psa.shadow"
unset MYVALS PID_FILE TMPDIR
if [[ -r "${PLESK_FILE}" ]]; then
...
Tested it and it works.
The text was updated successfully, but these errors were encountered:
Hi @pksteyn thanks for reporting this issue, you're right the definition of PLESK_FILE is missing in the print_mysql_innodb_status, would you mind submitting a PR for it? Happy to have that one reviewed.
MySQL core functionality uses variable PLESK_FILE to identify Plesk servers, and based on that will use the content of that file as the password when logging in as the MySQL admin user. E.g. in /usr/lib/recap/core/mysql:
...
local PLESK_FILE="/etc/psa/.psa.shadow"
if [[ -r "${PLESK_FILE}" ]]; then
echo "MySQL (plesk) status" >> "${LOGFILE}"
mysqladmin
-uadmin
-p$(cat "${PLESK_FILE}")
--connect-timeout=5
...
However, the variable is set as local and only in the functions print_mysql print_mysql_procs. This means function print_mysql_innodb_status doesn't have access to the variable, which results in it trying to use the MYCNF variable method to access MySQL, and fails unless the .my.cnf contains the correct credentials. And if the credentials are not correct then the InnoDB engine status is not logged.
The expected behaviour should be for function print_mysql_innodb_status to use the PLESK_FILE method on Plesk servers, but as the PLESK_FILE is not set globally, and not set locally within the function, it doesn't do so. It looks like the correct way to address this would either be to set PLESK_FILE as a global variable, or set it locally in the print_mysql_innodb_status function. Currently the function starts as:
...
print_mysql_innodb_status() {
log INFO "Starting 'mysql innodb' report - ${LOGFILE##*/}"
local LOGFILE="$1"
local MYCNF="$2"
local mysql_cmd=''
unset MYVALS PID_FILE TMPDIR
if [[ -r "${PLESK_FILE}" ]]; then
...
The suggestion is to set the PLESK_FILE variable locally:
...
print_mysql_innodb_status() {
log INFO "Starting 'mysql innodb' report - ${LOGFILE##*/}"
local LOGFILE="$1"
local MYCNF="$2"
local mysql_cmd=''
local PLESK_FILE="/etc/psa/.psa.shadow"
unset MYVALS PID_FILE TMPDIR
if [[ -r "${PLESK_FILE}" ]]; then
...
Tested it and it works.
The text was updated successfully, but these errors were encountered: