Fix of Bug#25088048 caused paths to be relative, not absolute, this
proved to be problematic.
Fix is to still ignore current working directory, however switch to
using full path of basedir, which is set to parent directory of bin/
directory where mysqld_safe is located.
References to legacy tool mysql_print_defaults are removed, only
my_print_defaults is used these days.
This will also fix:
Bug#11745176 (11192) MYSQLD_SAFE ONLY EVALUATES --DEFAULTS-FILE OPTION WHEN IT IS THE FIRST OP
Bug#23013510 (80866) MYSQLD_SAFE SHOULD NOT SEARCH $MY_BASEDIR_VERSION/VAR AS DATADIR
Bug#25244898 (84173) MYSQLD_SAFE --NO-DEFAULTS & SILENTLY DOES NOT WORK ANY MORE
Bug#25261472 (84219) INITSCRIPT ERRORS WHEN LAUCHING MYSQLD_SAFE IN NON DEFAULT BASEDIR
Bug#25319392 (84263) MYSQL.SERVER (MYSQL SERVER STARTUP SCRIPT) CAN NOT WORK,AND EXPORT SOME ERROR.
Bug#25319457 MYSQLD_SAFE MIGHT FAIL IF $DATADIR HAS TRAILING /
Bug#25341981 MYSQLD_SAFE ASSUMES INCORRECT BASEDIR WHEN EXECUTED WITH ABSOLUTE PATH
Bug#25356221 (84427) MYSQLD_SAFE FAILS TO START WHEN USING A FIFO FOR LOG-ERROR (REGRESSION)
Bug#25365194 (84447) MYSQLD_SAFE DOESN'T CHECK EXISTENCE OF GIVEN BASEDIR PARAMETER
Bug#25377815 ERRORS WHILE STARTING MYSQLD_SAFE WITH SYM LINK ENABLED
* Update mysqld_safe script to remove duplicated parameter --crash-script
* Make --core-file-size accept underscores as well as dashes correctly.
* Add mysqld_safe_helper to Debian and Ubuntu files.
* Update innodb minor version to 35
IS STARTING: CONFUSING ERROR
DESCRIPTION
===========
When mysql server processes transactions but has not yet
committed and shuts down abnormally (due to crash, external
killing etc.), a recovery is due from Storage engine side
which takes place the next time mysql server (either
through mysqld or mysqld_safe) is run.
While the 1st server is in mid of recovery, if another
instance of mysqld_safe is made to run, it may result into
2nd instance killing the 1st one after a moment.
ANALYSIS
========
In the "while true" loop, we've a check (which is done
after the server stops) for the existence of pid file to
enquire if it was a normal shutdown or not. If the file is
absent, it means that the graceful exit of server had
removed this file.
However if the file is present, the scripts makes a plain
assumption that this file is leftover of the "current"
server. It misses to consider that it could be a valid pid
file belonging to another running mysql server.
We need to add more checks in the latter case. The script
should extract the PID from this existing file and check if
its running or not. If yes, it means an older instance of
mysql server is running and hence the script should abort.
FIX
===
Checking the status of process (alive or not) by adding a
@CHECK_PID@ in such a case. Aborting if its alive. Detailed
logic is as follows:
- The mysqld_safe script would quit at start only as soon
as it finds that there is an active PID i.e. a mysql server
is already running.
- The PID file creation takes place after InnoDb recovery,
which means in rare case (when PID file isn't created yet)
it may happen that more than 1 server can come up but even
in that case others will have to wait till the 1st server
has released the acquired InnoDb lock. In this case all
these servers will either TIMEOUT waiting for InnoDb lock
or after this they would find that the 1st server is
already running (by reading $pid_file) and would abort.
- Our core fix is that we now check the status of mysql
server process (alive or not) after the server stops
running within the loop of "run -> shutdown/kill/abort ->
run ... ", so that only the script who owns the mysql
server would be able to bring it down if required.
NOTE
====
Removed the deletion of pid file and socket file from entry
of the loop, as it may result in 2nd instance deleting
these files created by 1st instance in RACE condition.
Compensated this by deleting these files at end of the loop
Reverted the changes made in patch to Bug#16776528. So
after this patch is pushed, the concept of mysqld_safe.pid
would go altogether. This was required as the script was
deleting other instance's mysqld_safe.pid allowing multiple
mysqld_safe instances to run in parallel. This patch would
fix Bug#16776528 as well as the resources would be guarded
anyway by InnoDb lock + our planned 5.7 patch.
Don't read --ledir option from config file.
Ignore current working for finding location of mysqld
Remove use of chown/chmod in scripts.
Be helpful only when basedir is /var/log or /var/lib.
Removed unused systemd files for SLES.
Set explicit basedir in scripts.
- Remove use of touch and chmod.
- Restrict usage of chown to cases where target directory is /var/log.
- Due to limited feature set in /bin/sh on Solaris, /bin/bash will be
used on this platform.
- Give error if directory for UNIX socket file is missing.
- Privileged user should not log to files owned by different user
(mysqld will log as before).
Argument to malloc-lib must be included in restricted list of
directories, symlink guards added, and mysqld and mysqld-version
options restricted to command line only. Don't redirect errors to
stderr.
Let mysqld_safe_syslog.cnf force disable error log so that logging to syslog is
not affected by previous log_error setting.
Added handling of --skip-log-error to mysqld_safe.
some checks were "if [ -n "$err_log" ]", others were "if [ $want_syslog -eq 0 ]",
so when both are set, error log file was only partially initialized.
To avoid this ambiguity we reset want_syslog when error log file is used.
Problem Description:
A mysqld_safe instance is started. An InnoDB crash recovery begins which takes
few seconds to complete. During this crash recovery process happening, another
mysqld_safe instance is started with the same server startup parameters. Since
the mysqld's pid file is absent during the crash recovery process the second
instance assumes there is no other process and tries to acquire a lock on the
ibdata files in the datadir. But this step fails and the 2nd instance keeps
retrying 100 times each with a delay of 1 second. Now after the 100 attempts,
the server goes down, but while going down it hits the mysqld_safe script's
cleanup section and without any check it blindly deletes the socket and pid
files. Since no lock is placed on the socket file, it gets deleted.
Solution:
We create a mysqld_safe.pid file in the datadir, which protects the presence
server instance resources by storing the mysqld_safe's process id in it. We
place a check if the mysqld_safe.pid file is existing in the datadir. If yes
then we check if the pid it contains is an active pid or not. If yes again,
then the scripts logs an error saying "A mysqld_safe instance is already
running". Otherwise it will log the present mysqld_safe's pid into the
mysqld_safe.pid file.
Problem Description:
A mysqld_safe instance is started. An InnoDB crash recovery begins which takes
few seconds to complete. During this crash recovery process happening, another
mysqld_safe instance is started with the same server startup parameters. Since
the mysqld's pid file is absent during the crash recovery process the second
instance assumes there is no other process and tries to acquire a lock on the
ibdata files in the datadir. But this step fails and the 2nd instance keeps
retrying 100 times each with a delay of 1 second. Now after the 100 attempts,
the server goes down, but while going down it hits the mysqld_safe script's
cleanup section and without any check it blindly deletes the socket and pid
files. Since no lock is placed on the socket file, it gets deleted.
Solution:
We create a mysqld_safe.pid file in the datadir, which protects the presence
server instance resources by storing the mysqld_safe's process id in it. We
place a check if the mysqld_safe.pid file is existing in the datadir. If yes
then we check if the pid it contains is an active pid or not. If yes again,
then the scripts logs an error saying "A mysqld_safe instance is already
running". Otherwise it will log the present mysqld_safe's pid into the
mysqld_safe.pid file.
Problem Description:
A mysqld_safe instance is started. An InnoDB crash recovery begins which takes
few seconds to complete. During this crash recovery process happening, another
mysqld_safe instance is started with the same server startup parameters. Since
the mysqld's pid file is absent during the crash recovery process the second
instance assumes there is no other process and tries to acquire a lock on the
ibdata files in the datadir. But this step fails and the 2nd instance keeps
retrying 100 times each with a delay of 1 second. Now after the 100 attempts,
the server goes down, but while going down it hits the mysqld_safe script's
cleanup section and without any check it blindly deletes the socket and pid
files. Since no lock is placed on the socket file, it gets deleted.
Solution:
We create a mysqld_safe.pid file in the datadir, which protects the presence
server instance resources by storing the mysqld_safe's process id in it. We
place a check if the mysqld_safe.pid file is existing in the datadir. If yes
then we check if the pid it contains is an active pid or not. If yes again,
then the scripts logs an error saying "A mysqld_safe instance is already
running". Otherwise it will log the present mysqld_safe's pid into the
mysqld_safe.pid file.
Problem Description:
A mysqld_safe instance is started. An InnoDB crash recovery begins which takes
few seconds to complete. During this crash recovery process happening, another
mysqld_safe instance is started with the same server startup parameters. Since
the mysqld's pid file is absent during the crash recovery process the second
instance assumes there is no other process and tries to acquire a lock on the
ibdata files in the datadir. But this step fails and the 2nd instance keeps
retrying 100 times each with a delay of 1 second. Now after the 100 attempts,
the server goes down, but while going down it hits the mysqld_safe script's
cleanup section and without any check it blindly deletes the socket and pid
files. Since no lock is placed on the socket file, it gets deleted.
Solution:
We create a mysqld_safe.pid file in the datadir, which protects the presence
server instance resources by storing the mysqld_safe's process id in it. We
place a check if the mysqld_safe.pid file is existing in the datadir. If yes
then we check if the pid it contains is an active pid or not. If yes again,
then the scripts logs an error saying "A mysqld_safe instance is already
running". Otherwise it will log the present mysqld_safe's pid into the
mysqld_safe.pid file.
Trivial cleanup
scripts/mysqld_safe.sh:
Added support for --crash-script.
Don't remove socket file (not needed as server will re-create it if needed)
Patch by Eric Bergen
storage/maria/ha_maria.h:
Removed not existing variable.
Some shell interpreters do not support '-e' test
primary to construct conditions.
man test 1 (on S10)
...skip...
-e file True if file exists. (Not available in sh.)
...skip...
Hence, check for the existence of a file using
'-e' might result in a syntax error on such
shell programs.
Fixed by replacing it by '-f'.
Some shell interpreters do not support '-e' test
primary to construct conditions.
man test 1 (on S10)
...skip...
-e file True if file exists. (Not available in sh.)
...skip...
Hence, check for the existence of a file using
'-e' might result in a syntax error on such
shell programs.
Fixed by replacing it by '-f'.
mysqld_safe script did not heed MySQL specific environment variable
$UMASK, leading to divergent behavior between mysqld and mysqld_safe.
Patch adds an approximation of mysqld's behavior to mysqld_safe,
within the bounds dictated by attempt to have mysqld_safe run on
even the most basic of shells (proper '70s sh, not just bash
with a fancy symlink).
Patch also adds approximation of said behavior to mysqld_multi
(in perl).
(backport)
manual merge
