[MDEV-4719] MariaDB can't start while bootup but it can start by "service mysql start" Created: 2013-06-27  Updated: 2019-12-14  Resolved: 2019-12-14

Status: Closed
Project: MariaDB Server
Component/s: Galera
Affects Version/s: 5.5.29-galera
Fix Version/s: N/A

Type: Bug Priority: Minor
Reporter: Eddy Lai Assignee: Jan Lindström (Inactive)
Resolution: Won't Fix Votes: 0
Labels: galera
Environment:

CentOS 6.4 running i ESXi 5.0



 Description   

A machine it can start MariaDB without problem by running "service mysql start". However it can't start while it is boot up.

The MariaDB setting as :

[mariadb]
wsrep_provider = /usr/lib64/galera/libgalera_smm.so
wsrep_retry_autocommit = 0
wsrep_cluster_name = 'cluster_db'
wsrep_sst_method = rsync
wsrep_cluster_address = 'gcomm://172.17.113.84'
wsrep_node_incoming_address = '172.17.113.239'
wsrep_node_address = '172.17.113.239'

The error log :

130627 16:18:45 [Note] WSREP: (2f8de7d6-df02-11e2-0800-19a94e29eb0c, 'tcp://0.0.0.0:4567') multicast: , ttl: 1
130627 16:33:26 [Note] WSREP: EVS version 0
130627 16:33:26 [Note] WSREP: PC version 0
130627 16:33:26 [Note] WSREP: gcomm: connecting to group 'cluster_db', peer '172.17.113.84:'
130627 16:33:26 [ERROR] WSREP: Permission denied
130627 16:33:26 [ERROR] WSREP: failed to open gcomm backend connection: 13: error while trying to listen 'tcp://0.0.0.0:4567?socket.non_blocking=1', asio error 'Permission denied': 13 (Permission denied)
         at gcomm/src/asio_tcp.cpp:listen():808
130627 16:33:26 [ERROR] WSREP: gcs/src/gcs_core.c:gcs_core_open():195: Failed to open backend connection: -13 (Permission denied)
130627 16:33:26 [ERROR] WSREP: gcs/src/gcs.c:gcs_open():1290: Failed to open channel 'cluster_db' at 'gcomm://172.17.113.84': -13 (Permission denied)
130627 16:33:26 [ERROR] WSREP: gcs connect failed: Permission denied
130627 16:33:26 [ERROR] WSREP: wsrep::connect() failed: 6
130627 16:33:26 [ERROR] Aborting

If running by "service mysql start", the logging is :

130627 16:35:23 [Note] WSREP: (8288ae1a-df04-11e2-0800-2779113716ed, 'tcp://0.0.0.0:4567') multicast: , ttl: 1
130627 16:35:23 [Note] WSREP: EVS version 0
130627 16:35:23 [Note] WSREP: PC version 0
130627 16:35:23 [Note] WSREP: gcomm: connecting to group 'cluster_db', peer '172.17.113.84:'
130627 16:35:23 [Note] WSREP: (8288ae1a-df04-11e2-0800-2779113716ed, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://172.17.113.226:4567
130627 16:35:24 [Note] WSREP: (8288ae1a-df04-11e2-0800-2779113716ed, 'tcp://0.0.0.0:4567') turning message relay requesting off
130627 16:35:24 [Note] WSREP: declaring 106ba418-def4-11e2-0800-d23b2dc3d420 stable
130627 16:35:24 [Note] WSREP: declaring 942d9a32-df00-11e2-0800-4f8fb8ad9dcd stable



 Comments   
Comment by Eddy Lai [ 2013-06-27 ]

The CentOS didn't enable selinux function.

Comment by Eddy Lai [ 2013-06-27 ]

MariaDB 5.5.31 installed by RPM.

Comment by Elena Stepanova [ 2013-06-27 ]

Hi,

it cannot be MariaDB 5.5.31, you are using MariaDB-Galera cluster, for which 5.5.31 version has not been released yet.
Could you please double-check the version? e.g. through mysqld --version

Thanks.

Comment by Eddy Lai [ 2013-06-28 ]

using mysql --version, the result is :
mysql Ver 15.1 Distrib 5.5.31-MariaDB, for Linux (x86_64) using readline 5.1

Comment by Elena Stepanova [ 2013-06-28 ]

It's a client version, which is irrelevant. Please check the server version.

Comment by Eddy Lai [ 2013-06-28 ]

sorry, the version is
mysqld --version
mysqld Ver 5.5.29-MariaDB for Linux on x86_64 (MariaDB Server, wsrep_23.7.3.rXXXX)

Comment by Nirbhay Choubey (Inactive) [ 2014-07-16 ]

It looks like a typical case of SELinux case. I see that you did disable SELinux. How did you do that? via 'setenforce' or /etc/selinux/config? If its modified using setenforce, it will get back to "Enforcing" on boot and thus will prevent mysqld to start. I tried to boot into "Permissive" CentOS-6.5 with mariadb-galera-5.5.38 installed with no problem.

Comment by Jan Lindström (Inactive) [ 2019-12-14 ]

Support for 5.5-galera has ended.

Generated at Thu Feb 08 06:58:37 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.