• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Forwarded to devs mysqld service is being restarted as part of microupdate - long service downtime

burnley

Regular Pleskian
TITLE:
mysqld service is being restarted as part of microupdate - long service downtime
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:
Plesk Onyx Version 17.5.3 Update #38‪, CentOS Linux 7.4.1708 (Core)‬
PROBLEM DESCRIPTION:
When running the micro update mysqld service gets restarted, leading to more than 5 minutes of downtime on servers running large databases. Unless there is a valid technical reason for restarting mysqld during the micro update I consider this as a bug that leads to service degradation and poor customer experience.
mysqld is relied upon by the single 2 most critical services on a Plesk server: www and email. If you shut it down you're disrupting normal client activity. The worst impact is by far on the email POP3 and IMAP services, with the clients starting to see authentication errors and being asked to enter their passwords again. In rare cases computers running Windows and using M$ Outlook require a reboot.​
STEPS TO REPRODUCE:
Update from #38 to #40.​
ACTUAL RESULT:
mysqld service gets restarted, taking down​
EXPECTED RESULT:
If mysqld doesn't need a restart, DO NOT RESTART IT!​
ANY ADDITIONAL INFORMATION:
YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:
Confirm bug
 
Thank you for report. From our developer:

Cannot reproduce. mariadb.service is not restarted during plesk installer update --repatch and MU scripts do not restart MySQL.

mysqld is relied upon by the single 2 most critical services on a Plesk server: www and email. If you shut it down you're disrupting normal client activity. The worst impact is by far on the email POP3 and IMAP services, with the clients starting to see authentication errors and being asked to enter their passwords again. In rare cases computers running Windows and using M$ Outlook require a reboot.

Sorry, but this is also completely not true. MySQL is not accessed from email subsystem.
 
Igor, thanks for the follow-up I stand corrected on the mail subsystem, I stopped mysqld and I can still authenticate the IMAP & POP3 users, which is good. However, in our environment mysqld was still restarted as part of the Plesk update. Wonder if this is happening for us because we're using the following symlinks in /etc/systemd/system for ease of management purposes:
lrwxrwxrwx 1 root root 39 Mar 2 2016 /etc/systemd/system/mysqld.service -> /usr/lib/systemd/system/mariadb.service
lrwxrwxrwx 1 root root 39 Mar 2 2016 /etc/systemd/system/mysql.service -> /usr/lib/systemd/system/mariadb.service
Consequently we can use:

systemctl status mariadb.service
● mariadb.service - MariaDB 10.1.31 database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/mariadb.service.d
└─migrated-from-my.cnf-settings.conf
Active: active (running) since Tue 2018-02-13 08:51:50 AEDT; 6 days ago
Docs: man:mysqld(8)
systemd
Main PID: 10998 (mysqld)
Status: "Taking your SQL requests now..."
CGroup: /system.slice/mariadb.service
└─10998 /usr/sbin/mysqld

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

systemctl status mysql.service
● mariadb.service - MariaDB 10.1.31 database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/mariadb.service.d
└─migrated-from-my.cnf-settings.conf
Active: active (running) since Tue 2018-02-13 08:51:50 AEDT; 6 days ago
Docs: man:mysqld(8)
systemd
Main PID: 10998 (mysqld)
Status: "Taking your SQL requests now..."
CGroup: /system.slice/mariadb.service
└─10998 /usr/sbin/mysqld

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

systemctl status mysqld.service
● mariadb.service - MariaDB 10.1.31 database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/mariadb.service.d
└─migrated-from-my.cnf-settings.conf
Active: active (running) since Tue 2018-02-13 08:51:50 AEDT; 6 days ago
Docs: man:mysqld(8)
systemd
Main PID: 10998 (mysqld)
Status: "Taking your SQL requests now..."
CGroup: /system.slice/mariadb.service
└─10998 /usr/sbin/mysqld

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
 
Igor, I'm seeing the same issue when upgrading to #41 on a test machine. At 14:32:23 local time mysqld was restarted. See the log entries in /var/log/plesk/install/autoinstaller3.log at the time:

[...]
[2018-02-22 14:32:17.762977] chsh: Shell not changed.
Changing shell for popuser.
chsh: Shell not changed.
Changing shell for mhandlers-user.
is running
Stopping sw_engine service... done
===> Cumulative APS controller database (apsc) upgrade has been started.
===> Cumulative upgrade of APS controller database has been completed.
===> Cumulative Plesk database upgrade (revertable stage) has been started.
===> Preparing Plesk database upgrade (revertable stage).
===> Cumulative upgrade of Plesk database (revertable stage) has been completed.
===> Plesk database scheme upgrade has been started.
Applying migrations from: /usr/local/psa/bootstrapper/pp17.5.3-bootstrapper/migrations/
===> Plesk database scheme upgrade has been completed.
Bootstrapper has finished action (exec time: 15 sec.): parent_name='panel', sequence='prep', stage='execute', sequence_order='0', operation='install', exec_cmd='/usr/local/psa/bootstrapper/pp17.5.3-bootstrapper/bootstrapper.sh prep-insta
ll BASE'', m_arch='', output: Changing shell for popuser.
Changing shell for mhandlers-user.
is running
Stopping sw_engine service... done
Applying migrations from: /usr/local/psa/bootstrapper/pp17.5.3-bootstrapper/migrations/

[2018-02-22 14:32:32.948609] Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
[...]

And in /var/log/messages:
[...]
Feb 22 14:32:19 plesk12 systemd: Stopped Plesk Panel.
Feb 22 14:32:19 plesk12 systemd: Stopping Plesk Panel...
Feb 22 14:32:19 plesk12 systemd: Stopping Startup script for Panel sw-engine...
Feb 22 14:32:19 plesk12 systemd: Stopped Startup script for Panel sw-engine.
Feb 22 14:32:20 plesk12 systemd-logind: New session 1960 of user root.
Feb 22 14:32:20 plesk12 systemd: Started Session 1960 of user root.
Feb 22 14:32:20 plesk12 systemd: Starting Session 1960 of user root.
Feb 22 14:32:23 plesk12 systemd: Stopping MariaDB 10.2.13 database server...
Feb 22 14:32:25 plesk12 systemd: Starting MariaDB 10.2.13 database server...
Feb 22 14:32:26 plesk12 mysqld: 2018-02-22 14:32:26 140525983643776 [Note] /usr/sbin/mysqld (mysqld 10.2.13-MariaDB-log) starting as process 18024 ...
Feb 22 14:32:29 plesk12 systemd: Started MariaDB 10.2.13 database server.
Feb 22 14:32:44 plesk12 yum[18614]: Updated: plesk-skins-17.5.3-cos7.build1705180207.18.noarch
Feb 22 14:33:14 plesk12 systemd: Stopping Startup script for Plesk control panel server...
Feb 22 14:33:14 plesk12 systemd: Stopped Startup script for Plesk control panel server.
Feb 22 14:33:16 plesk12 systemd: Starting Startup script for Panel sw-engine...
Feb 22 14:33:16 plesk12 systemd: Started Startup script for Panel sw-engine.
Feb 22 14:33:16 plesk12 systemd: Starting Startup script for Plesk control panel server...
Feb 22 14:33:17 plesk12 systemd: Failed to read PID from file /run/sw-cp-server.pid: Invalid argument
[...]

So somewhere in this 15 seconds time window a command was executed to restart , or stop/start one of these 3 possible services via systemd: mysql, mysqld, mariadb. Maybe during database upgrade? It'd be great if you can nail it and fix it, we can't afford restarting mysql at this point on the busy servers, makes no sense.
 
In /var/log/audit/audit.log:
type=SERVICE_START msg=audit(1519270339.372:15356): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=psa comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_STOP msg=audit(1519270339.372:15357): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=psa comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_START msg=audit(1519270339.435:15358): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sw-engine comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_STOP msg=audit(1519270339.435:15359): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sw-engine comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_START msg=audit(1519270345.784:15379): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=mariadb comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_STOP msg=audit(1519270345.784:15380): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=mariadb comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_START msg=audit(1519270349.416:15381): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=mariadb comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_START msg=audit(1519270394.891:15382): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sw-cp-server comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_STOP msg=audit(1519270394.891:15383): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sw-cp-server comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_START msg=audit(1519270396.453:15384): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sw-engine comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_START msg=audit(1519270397.172:15385): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sw-cp-server comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_START msg=audit(1519270416.526:15405): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=httpd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_STOP msg=audit(1519270416.526:15406): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=httpd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_START msg=audit(1519270426.419:15407): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=httpd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_START msg=audit(1519270438.084:15408): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sw-engine comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_STOP msg=audit(1519270438.084:15409): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sw-engine comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_START msg=audit(1519270438.196:15410): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sw-engine comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
 
Still cannot reproduce. Normally we try to avoid restarting all these services (mysql, sw-engine, sw-cp-server etc).
But maybe there are some extensions or additional components that perform that.

1. Can you show the list of installed components? E.g. by running "plesk installer --select-release-current --show-components"

2. If you are able to reproduce the problem on test machine can you run the update with debug output, i.e. "env PLESK_INSTALLER_DEBUG=1 plesk installer
" and attach autoinstaller3.log.
 
Thanks Igor, see below:
Still cannot reproduce. Normally we try to avoid restarting all these services (mysql, sw-engine, sw-cp-server etc).
But maybe there are some extensions or additional components that perform that.

1. Can you show the list of installed components? E.g. by running "plesk installer --select-release-current --show-components"
Detecting installed product components.
panel [up2date] - Plesk
bind [up2date] - BIND DNS server
postgresql [install] - PostgreSQL server
health-monitor [install] - Server Health Monitor
fail2ban [install] - Fail2Ban
selinux [up2date] - SELinux policy
l10n [up2date] - All language localization for Plesk
git [up2date] - Git
docker [install] - Docker
resctrl [install] - Resource Controller (Cgroups)
pmm [up2date] - Plesk Migrator
sitebuilder [up2date] - Web Presence Builder
mysqlgroup [up2date] - MySQL server
horde [up2date] - Horde
roundcube [up2date] - Roundcube
kav [install] - Kaspersky Anti-Virus
drweb [install] - Plesk Premium Antivirus
spamassassin [up2date] - SpamAssassin
mailman [up2date] - Mailman
postfix [up2date] - Postfix
qmail [install] - Qmail
msmtp [install] - MSMTP (relay only)
dovecot [up2date] - Dovecot
courier [install] - Courier
proftpd [up2date] - ProFTPD
java [install] - Support for Tomcat Java Servlets
webalizer [up2date] - Webalizer
awstats [up2date] - AWStats
modsecurity [install] - ModSecurity
passenger [up2date] - Phusion Passenger server
ruby [install] - Ruby support
nodejs [up2date] - NodeJS support
gems-pre [install] - Tools required for building Ruby gems
mod_fcgid [up2date] - mod_fcgid
mod_perl [up2date] - mod_perl
mod-bw [install] - mod_bw
webservers [up2date] - Apache
php7.2 [install] - PHP 7.2
php7.1 [install] - PHP 7.1
php7.0 [install] - PHP 7.0
php5.6 [install] - PHP 5.6
php5.5 [install] - PHP 5.5
php5.4 [install] - PHP 5.4
php5.3 [up2date] - PHP 5.3
php5.2 [up2date] - PHP 5.2
phpgroup [up2date] - PHP 5 from OS vendor
nginx [up2date] - Nginx web server
config-troubleshooter[up2date] - Plesk Web Server Configuration Troubleshooter
psa-firewall [install] - Plesk Firewall
psa-vpn [install] - Plesk VPN
psa-fileserver [install] - Plesk file server
watchdog [install] - Watchdog system monitoring
cloudflare [up2date] - Cloudflare ServerShield
magicspam [install] - MagicSpam Embedded Protection
heavy-metal-skin [up2date] - Skins and Color Schemes
wp-toolkit [up2date] - WordPress Toolkit
security-advisor [install] - Security Advisor
letsencrypt [install] - Let's Encrypt
2. If you are able to reproduce the problem on test machine can you run the update with debug output, i.e. "env PLESK_INSTALLER_DEBUG=1 plesk installer" and attach autoinstaller3.log.
Plesk is up to date on the test machine, I'll have to convince it to reinstall the patches. Let me see what I can do.
 
Ok, ran the following command:

env PLESK_INSTALLER_DEBUG=1 plesk installer --select-release-current --reinstall-patch --upgrade-installed-components

But I didn't replicate the issue because the test machine was already up to date, so Plesk just reapplied the patches, without executing the code that runs:

[2018-02-22 14:32:17.762977] chsh: Shell not changed.
Changing shell for popuser.
chsh: Shell not changed.
Changing shell for mhandlers-user.
is running
Stopping sw_engine service... done
===> Cumulative APS controller database (apsc) upgrade has been started.
===> Cumulative upgrade of APS controller database has been completed.
===> Cumulative Plesk database upgrade (revertable stage) has been started.
===> Preparing Plesk database upgrade (revertable stage).
===> Cumulative upgrade of Plesk database (revertable stage) has been completed.
===> Plesk database scheme upgrade has been started.
Applying migrations from: /usr/local/psa/bootstrapper/pp17.5.3-bootstrapper/migrations/
===> Plesk database scheme upgrade has been completed.
Bootstrapper has finished action (exec time: 15 sec.): parent_name='panel', sequence='prep', stage='execute', sequence_order='0', operation='install', exec_cmd='/usr/local/psa/bootstrapper/pp17.5.3-bootstrapper/bootstrapper.sh prep-insta
ll BASE'', m_arch='', output: Changing shell for popuser.
Changing shell for mhandlers-user.
is running
Stopping sw_engine service... done
Applying migrations from: /usr/local/psa/bootstrapper/pp17.5.3-bootstrapper/migrations/
[...]
 
Still not enough information.

Could you repeat update with "env PLESK_INSTALLER_DEBUG=1" after the next MU is published (I guess it was today)?
 
Yep, replicated with debugging enabled, thanks Igor :)
Looks like the installer is trying to enable the InnoDB engine when backing up / restoring the databases and is looking for "have_innodb" variable which doesn't exist in MariaDB 10.1 and 10.2. Unfortunately I haven't got a 10.0 instance to test against.
There you go:
[...]
+ /usr/bin/mysqldump --user=admin --quote-names --add-drop-database --databases mysql psa apsc horde
+ rc=0
+ unset MYSQL_PWD
+ return 0
+ suc
+ p_echo done
+ '[' -n 1 -o -n '' -o -z /var/log/plesk/install/plesk_17.5.3_installation.log ']'
+ echo done
+ p_echo ' MySQL databases are dumped to /var/lib/psa/dumps/mysql.preupgrade.17.5.3-17.5.3.20180227-091316.dump.gz'
+ '[' -n 1 -o -n '' -o -z /var/log/plesk/install/plesk_17.5.3_installation.log ']'
+ echo ' MySQL databases are dumped to /var/lib/psa/dumps/mysql.preupgrade.17.5.3-17.5.3.20180227-091316.dump.gz'
+ unset MYSQLDUMP_OPTIONS
+ SAFE_PREP_DB_BACKUP=/var/lib/psa/dumps/mysql.preupgrade.17.5.3-17.5.3.20180227-091316.dump.gz
+ transaction_add_rollback_action safe_prep_db_upgrade_rollback
+ '[' -z true ']'
+ '[' -z 'core_start_product_on_rollback base_rollback_product_config_default base_rollback_product_config show_report_after_rollback unlock_bootstrapper' ']'
+ TRANSACTION_ROLLBACK_FUNCS='safe_prep_db_upgrade_rollback core_start_product_on_rollback base_rollback_product_config_default base_rollback_product_config show_report_after_rollback unlock_bootstrapper'
+ enable_innodb_engine
+ local have_innodb=
+ '[' -z '' ']'
+ local mysql_db_name=mysql
+ local db_select_output=
+ db_select 'SHOW VARIABLES LIKE '\''have_innodb'\'''
+ local 'desc=execute SQL query'
+ local 'query=SHOW VARIABLES LIKE '\''have_innodb'\'''
++ mysql_raw -e 'SHOW VARIABLES LIKE '\''have_innodb'\'''
+ local output=
+ local status=0
+ '[' 0 -ne 0 ']'
+ db_select_output=
+ return 0
++ get_narg 2
++ shift 2
++ return 0
+ have_innodb=
+ '[' -n '' ']'
+ have_innodb=NO
+ echo_try 'allow INNODB engine'
+ msg='allow INNODB engine'
+ pnnl_echo ' Trying to allow INNODB engine... '
+ '[' -n 1 -o -n '' -o -z /var/log/plesk/install/plesk_17.5.3_installation.log ']'
+ echo -n ' Trying to allow INNODB engine... '
+ find_my_cnf
+ local non_fatal=
+ local 'cnf_files=/etc/my.cnf /etc/mysql/my.cnf /var/db/mysql/my.cnf'
+ for my_cnf in '$cnf_files'
+ '[' -f /etc/my.cnf ']'
+ break
+ '[' -f /etc/my.cnf -o -n '' ']'
+ '[' -f /etc/my.cnf ']'
+ grep -q '^skip-innodb' /etc/my.cnf
+ suc
+ p_echo done
+ '[' -n 1 -o -n '' -o -z /var/log/plesk/install/plesk_17.5.3_installation.log ']'
+ echo done
+ pnnl_echo 'Restarting mysql'
+ '[' -n 1 -o -n '' -o -z /var/log/plesk/install/plesk_17.5.3_installation.log ']'
+ echo -n 'Restarting mysql'
+ '[' 2 -le 2 ']'
+ local service_name=mysql
+ local action=restart
+ local ret=0
+ local inten
+ shift
+ shift
+ test linux = linux
+ is_function mysql_restart_linux_redhat
++ type -t mysql_restart_linux_redhat
+ local type_output=
+ test X = Xfunction
+ is_function mysql_restart_linux
++ type -t mysql_restart_linux
+ local type_output=
+ test X = Xfunction
+ is_function mysql_restart
++ type -t mysql_restart
+ local type_output=
+ test X = Xfunction
+ eval 'service=$mysql_service'
++ service=mysql
+ '[' -n mysql ']'
+ inten='restart service mysql'
+ '[' restart = status -o restart = exists ']'
+ echo_try 'restart service mysql'
+ msg='restart service mysql'
+ pnnl_echo ' Trying to restart service mysql... '
+ '[' -n 1 -o -n '' -o -z /var/log/plesk/install/plesk_17.5.3_installation.log ']'
+ echo -n ' Trying to restart service mysql... '
+ local action=restart
+ local service=mysql
+ local service_name=mysql
+ '[' restart '!=' exists ']'
+ _service_exec mysql exists
+ local service=mysql
+ local action=exists
+ local action_cmd
+ local sysvinit_service=/etc/init.d/mysql
+ '[' -x /bin/systemctl ']'
+ case "${action}" in
+ /bin/systemctl list-unit-files
+ awk 'BEGIN { rc = 1 } $1 == "mysql.service" { rc = 0;} END { exit rc }'
+ return 0
+ '[' 0 '!=' 0 ']'
+ case "$action" in
+ pleskrc mysql status
+ '[' 2 -le 2 ']'
+ local service_name=mysql
+ local action=status
+ local ret=0
+ local inten
+ shift
+ shift
+ test linux = linux
+ is_function mysql_status_linux_redhat
++ type -t mysql_status_linux_redhat
+ local type_output=
+ test X = Xfunction
+ is_function mysql_status_linux
++ type -t mysql_status_linux
+ local type_output=
+ test X = Xfunction
+ is_function mysql_status
++ type -t mysql_status
+ local type_output=function
+ test Xfunction = Xfunction
+ mysql_status
+ local file
+ '[' Xredhat = Xdebian ']'
+ '[' -z yes ']'
+ '[' yes = yes ']'
+ service_ctl status mysql mysql
+ local action=status
+ local service=mysql
+ local service_name=mysql
+ '[' status '!=' exists ']'
+ _service_exec mysql exists
+ local service=mysql
+ local action=exists
+ local action_cmd
+ local sysvinit_service=/etc/init.d/mysql
+ '[' -x /bin/systemctl ']'
+ case "${action}" in
+ /bin/systemctl list-unit-files
+ awk 'BEGIN { rc = 1 } $1 == "mysql.service" { rc = 0;} END { exit rc }'
+ return 0
+ '[' 0 '!=' 0 ']'
+ case "$action" in
+ _service_exec mysql status
+ local service=mysql
+ local action=status
+ local action_cmd
+ local sysvinit_service=/etc/init.d/mysql
+ '[' -x /bin/systemctl ']'
+ case "${action}" in
+ action=is-active
+ /bin/systemctl is-active mysql.service
+ return 0
+ return 0
+ _service_exec mysql restart
+ local service=mysql
+ local action=restart
+ local action_cmd
+ local sysvinit_service=/etc/init.d/mysql
+ '[' -x /bin/systemctl ']'
+ case "${action}" in
+ /bin/systemctl restart mysql.service
+ ret=0
+ '[' restart '!=' status -a restart '!=' exists ']'
+ '[' 0 -eq 0 ']'
+ suc
+ p_echo done
[...]
 
Thank you for additional information!
From developer:

Great!
I was able to reproduce the issue using new info from the customer, so I reported bug (PPP-29335) and linked the request (PPPM-8061).
 
Back
Top