[MDEV-9349] mysqld_safe bug with --basedir option Created: 2015-12-30  Updated: 2016-01-13  Resolved: 2016-01-13

Status: Closed
Project: MariaDB Server
Component/s: OTHER
Affects Version/s: 10.1.9
Fix Version/s: N/A

Type: Bug Priority: Minor
Reporter: Quanah Gibson-Mount (Inactive) Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Environment:

Linux (Any)


 Description   

When running multiple instances of mariadb, if mysqld_safe is passed the "basedir" option, it will fail to start the second instance of mariadb with:

[zimbra@zre-ldap005 ~]$ /opt/zimbra/common/bin/mysqld_safe --basedir=/opt/zimbra/common --defaults-file=/opt/zimbra/conf/antispam-my.cnf --external-locking --malloc-lib=/opt/zimbra/common/lib/libtcmalloc_minimal.so --datadir=/opt/zimbra/data/amavisd/mysql/data --log-error=/opt/zimbra/log/antispam-mysqld.log --ledir=/opt/zimbra/common/sbin
151230 14:57:42 mysqld_safe Adding '/opt/zimbra/common/lib/libtcmalloc_minimal.so' to LD_PRELOAD for mysqld
151230 14:57:43 mysqld_safe Logging to '/opt/zimbra/log/antispam-mysqld.log'.
151230 14:57:43 mysqld_safe A mysqld process already exists

Removing the --basedir option allows it to successfully start:
[zimbra@zre-ldap005 ~]$ /opt/zimbra/common/bin/mysqld_safe --defaults-file=/opt/zimbra/conf/antispam-my.cnf --external-locking --malloc-lib=/opt/zimbra/common/lib/libtcmalloc_minimal.so --datadir=/opt/zimbra/data/amavisd/mysql/data --log-error=/opt/zimbra/log/antispam-mysqld.log --ledir=/opt/zimbra/common/sbin 151230 14:58:04 mysqld_safe Adding '/opt/zimbra/common/lib/libtcmalloc_minimal.so' to LD_PRELOAD for mysqld
151230 14:58:04 mysqld_safe Logging to '/opt/zimbra/log/antispam-mysqld.log'.
151230 14:58:04 mysqld_safe Starting mysqld daemon with databases from /opt/zimbra/data/amavisd/mysql/data

Note that this is the exact basedir value provided in the cnf file:
[zimbra@zre-ldap005 conf]$ grep basedir antispam-my.cnf
basedir = /opt/zimbra/common

It appears the issue is that the other mysql instance is running with the same basedir value:
zimbra 2712 1 0 09:46 ? 00:00:00 /bin/sh /opt/zimbra/common/bin/mysqld_safe --defaults-file=/opt/zimbra/conf/my.cnf --external-locking --log-error=/opt/zimbra/log/mysql_error.log --malloc-lib=/opt/zimbra/common/lib/libtcmalloc_minimal.so --ledir=/opt/zimbra/common/sbin
zimbra 2917 2712 0 09:46 ? 00:00:14 /opt/zimbra/common/sbin/mysqld --defaults-file=/opt/zimbra/conf/my.cnf --basedir=/opt/zimbra/common --datadir=/opt/zimbra/db/data --plugin-dir=/opt/zimbra/common/lib/plugin --external-locking --log-error=/opt/zimbra/log/mysql_error.log --pid-file=/opt/zimbra/log/mysql.pid --socket=/opt/zimbra/data/tmp/mysql/mysql.sock --port=7306

However, there is nothing wrong with two instances of mysqld having the same value for basedir, as the entire point is for mysqld to be sharing the same binaries.

 Comments   
Comment by Elena Stepanova [ 2016-01-13 ]

There is indeed nothing wrong with running different instances of mysqld out of the same basedir, we do it all the time, it works just fine.

There is something wrong with your example though.
What is /opt/zimbra/common/bin/mysqld_safe – is it the regular mysqld_safe from MariaDB server, or did you override it with some kind of a wrapper with the same name?
If it's the regular script, then, regardless anything else, this command

/opt/zimbra/common/bin/mysqld_safe --basedir=/opt/zimbra/common --defaults-file=/opt/zimbra/conf/antispam-my.cnf ...

cannot work. It will pass both options in the same order to the server, and the server cannot handle defaults-file when it's not the first option.

However, it should just fail, and should not throw the message mysqld_safe A mysqld process already exists, this is also wrong. It happens when mysqld_safe finds a pid file in the location where it plans to create one, and when this pid file contains a pid of a process which is already running. There is no pid-file option on your command line, so I'm not sure what it will set it to, probably /opt/zimbra/data/amavisd/mysql/data/<hostname>.pid. So, if fixing the first part (the order or options) won't make the problem go away, check where it finds the pid file, and whether there is a process with the pid from this pid file.

Comment by Quanah Gibson-Mount (Inactive) [ 2016-01-13 ]

Ok, thanks for the info. It's interesting, because this used to work just fine with the order, and was this way for years. So something got more strict at some point. In any case, since we already define the basedir in the config file, I stopped passing it in as an option to msyqld_safe.

Comment by Elena Stepanova [ 2016-01-13 ]

Actually no, it has been like that for years. See 5.5.23 (this is 3.5 years ago):

basedir, then defaults-file

 
/data/releases/mariadb-5.5.23-linux-x86_64$ bin/mysqld_safe --basedir=/data/releases/mariadb-5.5.23-linux-x86_64 --defaults-file=/data/releases/mariadb-5.5.23-linux-x86_64/1.cnf --port=3310 --log-error=log.err &
 
 
 
/data/releases/mariadb-5.5.23-linux-x86_64$ 160113 02:32:36 mysqld_safe Logging to '/data/releases/mariadb-5.5.23-linux-x86_64/data/log.err'.
 
160113 02:32:36 mysqld_safe Starting mysqld daemon with databases from /data/releases/mariadb-5.5.23-linux-x86_64/data
 
/data/releases/mariadb-5.5.23-linux-x86_64$ 160113 02:32:38 mysqld_safe mysqld from pid file /data/releases/mariadb-5.5.23-linux-x86_64/data/wheezy-64.pid ended
 
 
 
/data/releases/mariadb-5.5.23-linux-x86_64$ tail data/log.err
 
160113  2:32:37 Percona XtraDB (http://www.percona.com) 1.1.8-24.1 started; log sequence number 1597945
 
160113  2:32:37 [Note] Plugin 'FEEDBACK' is disabled.
 
160113  2:32:37 [ERROR] /data/releases/mariadb-5.5.23-linux-x86_64/bin/mysqld: unknown variable 'defaults-file=/data/releases/mariadb-5.5.23-linux-x86_64/1.cnf'
 
160113  2:32:37 [ERROR] Aborting
 
 
 
160113  2:32:37  InnoDB: Starting shutdown...
 
160113  2:32:38  InnoDB: Shutdown completed; log sequence number 1597945
 
160113  2:32:38 [Note] /data/releases/mariadb-5.5.23-linux-x86_64/bin/mysqld: Shutdown complete
 
 
 
160113 02:32:38 mysqld_safe mysqld from pid file /data/releases/mariadb-5.5.23-linux-x86_64/data/wheezy-64.pid ended

defaults-file, then basedir

 
/data/releases/mariadb-5.5.23-linux-x86_64$ bin/mysqld_safe --defaults-file=/data/releases/mariadb-5.5.23-linux-x86_64/1.cnf --basedir=/data/releases/mariadb-5.5.23-linux-x86_64  --port=3310 --log-error=log.err &
 
=/data/releases/mariadb-5.5.23-linux-x86_64$ 160113 02:33:10 mysqld_safe Logging to '/data/releases/mariadb-5.5.23-linux-x86_64/data/log.err'.
 
160113 02:33:10 mysqld_safe Starting mysqld daemon with databases from /data/releases/mariadb-5.5.23-linux-x86_64/data
 
 
 
/data/releases/mariadb-5.5.23-linux-x86_64$ 
/data/releases/mariadb-5.5.23-linux-x86_64$ tail data/log.err
 
160113  2:33:10 InnoDB: Compressed tables use zlib 1.2.3
 
160113  2:33:10 InnoDB: Initializing buffer pool, size = 128.0M
 
160113  2:33:10 InnoDB: Completed initialization of buffer pool
 
160113  2:33:10 InnoDB: highest supported file format is Barracuda.
 
160113  2:33:11  InnoDB: Waiting for the background threads to start
 
160113  2:33:12 Percona XtraDB (http://www.percona.com) 1.1.8-24.1 started; log sequence number 1597945
 
160113  2:33:12 [Note] Plugin 'FEEDBACK' is disabled.
 
160113  2:33:12 [Note] Event Scheduler: Loaded 0 events
 
160113  2:33:12 [Note] /data/releases/mariadb-5.5.23-linux-x86_64/bin/mysqld: ready for connections.
 
Version: '5.5.23-MariaDB'  socket: '/tmp/mysql.sock'  port: 3310  MariaDB Server

If it had ever been different for you, maybe you really had a customized mysqld_safe script.

Comment by Quanah Gibson-Mount (Inactive) [ 2016-01-13 ]

Yeah, this portion of our code was unused for many years. I.e., 5.0 or before. It wasn't until I dusted it off that I found that it had stopped working.

Generated at Thu Feb 08 07:33:59 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.