Bug 259795 - databases/galera26: cannot initialize new cluster
Summary: databases/galera26: cannot initialize new cluster
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
Depends on:
Reported: 2021-11-12 11:12 UTC by Lapo Luchini
Modified: 2021-12-17 08:29 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (devel)

complete error log (8.52 KB, text/plain)
2021-11-12 11:12 UTC, Lapo Luchini
no flags Details
Galera Cluster Full log (9.69 KB, text/plain)
2021-12-07 10:06 UTC, Albert Valbuena
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lapo Luchini 2021-11-12 11:12:01 UTC
Created attachment 229446 [details]
complete error log

I have a strange problem: I cannot initialize a new (MAriaDB 10.5) Galera cluster, doing the same things that I did a few months ago to set-up a similar cluster.

# cp /usr/local/etc/mysql/conf.d/wsrep.cnf.sample /usr/local/etc/mysql/conf.d/wsrep.cnf
# nano /usr/local/etc/mysql/conf.d/wsrep.cnf

and I only changed: wsrep_provider, wsrep_cluster_name, wsrep_cluster_address, wsrep_sst_method, wsrep_sst_auth.

I get this error:

2021-11-12 12:08:37 0 [ERROR] WSREP: exception from gcomm, backend must be restarted: failed to set FD_CLOEXEC: 9 (Bad file descriptor)
         at /wrkdirs/usr/ports/databases/galera26/work/galera-release_26.4.9/galerautils/src/gu_asio_socket_util.hpp:set_fd_options():41

Moreover, at the end I get this unexpected behavior that it cannot be stopped but there is some lingering process:

# service mysql-server onestop
mysql not running? (check /var/run/mysql/mysqld.pid).
# pgrep maria

Is this a known bug?
Is there a way to debug which socket is not accepting FD_CLOEXEC?
(maybe with truss? but the rc.d startup is a bit complex)
Comment 1 Albert Valbuena 2021-12-07 10:04:46 UTC
I'm experiencing the same issue.

Current config in /etc/rc.conf


Current config at /usr/local/etc/mysql/my.cnf

[albert@Cluster1 ~]$ cat /usr/local/etc/mysql/my.cnf
# This group is read both by the client and the server
# use it for options that affect everything, see
# https://mariadb.com/kb/en/configuring-mariadb-with-option-files/#option-groups
port    = 3306
socket  = /var/run/mysql/mysql.sock

# include *.cnf from the config directory
!includedir /usr/local/etc/mysql/conf.d/
[albert@Cluster1 ~]$

Current config at /usr/local/etc/mysl/conf.d/wsrep.cnf

[albert@Cluster1 /usr/local/etc/mysql/conf.d]$ cat wsrep.cnf
# This file contains wsrep-related mysqld options. It should be included
# in the main MySQL configuration file.
# Options that need to be customized:
#  - wsrep_provider
#  - wsrep_cluster_address
#  - wsrep_sst_auth
# The rest of defaults should work out of the box.

## mysqld options _MANDATORY_ for correct opration of the cluster

# (This must be substituted by wsrep_format)

# Currently only InnoDB storage engine is supported

# to avoid issues with 'bulk mode inserts' using autoinc

# Override bind-address
# In some systems bind-address defaults to, and with mysqldump SST
# it will have (most likely) disastrous consequences on donor node

## WSREP options

# Enable wsrep

# Full path to wsrep provider library or 'none'

# Provider specific configuration options

# Logical cluster name. Should be the same for all nodes.

# Group communication system handle

# Human-readable node name (non-unique). Hostname by default.

# Base replication <address|hostname>[:port] of the node.
# The values supplied will be used as defaults for state transfer receiving,
# listening ports and so on. Default: address of the first network interface.

# Address for incoming client connections. Autodetect by default.

# How many threads will process writesets from other nodes

# DBUG options for wsrep provider

# Generate fake primary keys for non-PK tables (required for multi-master
# and parallel applying operation)

# Maximum number of rows in write set

# Maximum size of write set

# to enable debug level logging, set this to 1

# convert locking sessions into transactions

# how many times to retry deadlocked autocommits

# change auto_increment_increment and auto_increment_offset automatically

# retry autoinc insert, which failed for duplicate key error

# enable "strictly synchronous" semantics for read operations

# Command to call when node status or cluster membership changes.
# Will be passed all or some of the following options:
# --status  - new status of this node
# --uuid    - UUID of the cluster
# --primary - whether the component is primary or not ("yes"/"no")
# --members - comma-separated list of members
# --index   - index of this node in the list

## WSREP State Transfer options

# State Snapshot Transfer method

# Address which donor should send State Snapshot to.
# Should be the address of THIS node. DON'T SET IT TO DONOR ADDRESS!!!
# (SST method dependent. Defaults to the first IP of the first interface)

# SST authentication string. This will be used to send SST to joining nodes.
# Depends on SST method. For mysqldump method it is root:<root password>

# Desired SST donor name.

# Reject client queries when donating SST (false)

# Protocol version to use
# wsrep_protocol_version=
[albert@Cluster1 /usr/local/etc/mysql/conf.d]$

The mysql-server status output is the service isn't running.

[albert@Cluster1 /usr/local/etc/mysql/conf.d]$ sudo service mysql-server status
mysql is not running.
[albert@Cluster1 /usr/local/etc/mysql/conf.d]$

However, there are two mysql processes running. But yes, MariaDB is unsuable.

[albert@Cluster1 /usr/local/etc/mysql/conf.d]$ ps aux | grep mysql
mysql  2625   0.0  0.2  13628  3168  -  Is   00:15    0:00.01 /bin/sh /usr/local/bin/mariadbd-safe --defaults-extra-file=/usr/local/etc/mysql/my.cnf --user=mysql --datadir=/var/db/mysql --
mysql  2922   0.0  2.4 215076 49064  -  I    00:15    0:00.05 /usr/local/libexec/mariadbd --defaults-extra-file=/usr/local/etc/mysql/my.cnf --basedir=/usr/local --datadir=/var/db/mysql --p
albert 2944   0.0  0.0    432   244  1  R+   00:16    0:00.00 grep mysql
[albert@Cluster1 /usr/local/etc/mysql/conf.d]$
Comment 2 Albert Valbuena 2021-12-07 10:06:31 UTC
Created attachment 229954 [details]
Galera Cluster Full log
Comment 3 Lapo Luchini 2021-12-17 08:29:14 UTC
In the meanwhile I tried with MariaDB 10.3 and cluster creation went smoothly (with identical configuration). Seems to be a regression.