Hi all,

Patching one of our spare servers this morning and ran into a couple of issues.  The first was a complaint in the service status:

mariadb.service: Referenced but unset environment variable evaluates to an empty string: MYSQLD_OPTS, _WSREP_NEW_CLUSTER

Which was fixed by running systemctl edit mariadb.service and adding

Environment="MYSQLD_OPTS="
Environment="_WSREP_NEW_CLUSTER="

to the end of the file.

The second was from the error log which stated that the service was unable to read /etc/mysql/rest/keyfile.passwd, which turned out to be a permissions error on /etc/mysql/rest which was 600 and not 700 (I checked the other servers and theirs were also 600 so I guess it's the fix for MDEV-36229 which caused that)

Now the server starts but it core dumps almost immediately.  Systemctl status shows:

● mariadb.service - MariaDB 11.4.7 database server
     Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/mariadb.service.d
             └─migrated-from-my.cnf-settings.conf, override.conf
     Active: activating (auto-restart) (Result: core-dump) since Sat 2025-06-07 12:45:30 UTC; 1s ago
       Docs: man:mariadbd(8)
             https://mariadb.com/kb/en/library/systemd/
    Process: 26495 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
    Process: 26497 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
    Process: 26500 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
    Process: 26684 ExecStart=/usr/sbin/mariadbd $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=dumped, signal=SEGV)
   Main PID: 26684 (code=dumped, signal=SEGV)
        CPU: 1.136s

and error log shows

2025-06-07 12:33:57 0 [Note] Starting MariaDB 11.4.7-MariaDB-ubu2404-log source revision 118cfcf82107188f2295631193658b2ef94f4f3f server_uid 7bAWQJ3wkO2Wd/rTUTlrW6jyD3E= as process 4209
2025-06-07 12:33:57 0 [Note] InnoDB: Compressed tables use zlib 1.3
2025-06-07 12:33:57 0 [Note] InnoDB: Number of transaction pools: 1
2025-06-07 12:33:57 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2025-06-07 12:33:57 0 [Note] InnoDB: Using liburing
2025-06-07 12:33:57 0 [Note] InnoDB: innodb_buffer_pool_size_max=22528m, innodb_buffer_pool_size=22528m
2025-06-07 12:33:58 0 [Note] InnoDB: Initialized memory pressure event listener
2025-06-07 12:33:58 0 [Note] InnoDB: Completed initialization of buffer pool
2025-06-07 12:33:58 0 [Note] InnoDB: File system buffers for log disabled (block size=512 bytes)
2025-06-07 12:33:58 0 [Note] InnoDB: Resetting space id's in the doublewrite buffer
2025-06-07 12:33:58 0 [Note] InnoDB: End of log at LSN=43439159458895
2025-06-07 12:33:58 0 [Note] InnoDB: Opened 3 undo tablespaces
2025-06-07 12:33:58 0 [Note] InnoDB: 128 rollback segments in 3 undo tablespaces are active.
2025-06-07 12:33:58 0 [Warning] InnoDB: Cannot free the unused segments in system tablespace because a previous shutdown was not with innodb_fast_shutdown=0 or XA PREPARE transactions exist
2025-06-07 12:33:58 0 [Note] InnoDB: System tablespace defragmentation process starts
2025-06-07 12:33:58 0 [Note] InnoDB: Moving the data from extents 15552 through 2452672
250607 12:33:58 [ERROR] /usr/sbin/mariadbd got signal 11 ;
Sorry, we probably made a mistake, and this is a bug.

Your assistance in bug reporting will enable us to fix this for the next release.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs about how to report
a bug on https://jira.mariadb.org/.

Please include the information from the server start above, to the end of the
information below.

Server version: 11.4.7-MariaDB-ubu2404-log source revision: 118cfcf82107188f2295631193658b2ef94f4f3f

The information page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mariadbd/
contains instructions to obtain a better version of the backtrace below.
Following these instructions will help MariaDB developers provide a fix quicker.

Attempting backtrace. Include this in the bug report.
(note: Retrieving this information may fail)

Thread pointer: 0x0
stack_bottom = 0x0 thread_stack 0x30000
/usr/sbin/mariadbd(my_print_stacktrace+0x30)[0x5a41189db560]
/usr/sbin/mariadbd(handle_fatal_signal+0x2a1)[0x5a4118574ae1]
/lib/x86_64-linux-gnu/libc.so.6(+0x45330)[0x7650bf845330]
/usr/sbin/mariadbd(+0x636615)[0x5a41180bb615]
/usr/sbin/mariadbd(+0x1043036)[0x5a4118ac8036]
/usr/sbin/mariadbd(+0xec468d)[0x5a411894968d]
/usr/sbin/mariadbd(+0x622c5a)[0x5a41180a7c5a]
/usr/sbin/mariadbd(+0xd9b926)[0x5a4118820926]
/usr/sbin/mariadbd(_Z24ha_initialize_handlertonPv+0x8c)[0x5a411857717c]
/usr/sbin/mariadbd(+0x8165b3)[0x5a411829b5b3]
/usr/sbin/mariadbd(+0x8167a7)[0x5a411829b7a7]
/usr/sbin/mariadbd(_Z11plugin_initPiPPci+0xbfc)[0x5a41182a1e3c]
/usr/sbin/mariadbd(+0x6bbd65)[0x5a4118140d65]
/usr/sbin/mariadbd(_Z11mysqld_mainiPPc+0xf79)[0x5a4118144f79]
/lib/x86_64-linux-gnu/libc.so.6(+0x2a1ca)[0x7650bf82a1ca]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x8b)[0x7650bf82a28b]
/usr/sbin/mariadbd(_start+0x25)[0x5a411811e865]
Writing a core file...
Working directory at /var/lib/mysql
Resource Limits (excludes unlimited resources):
Limit                     Soft Limit           Hard Limit           Units     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max processes             139959               139959               processes
Max open files            1048576              1048576              files     
Max locked memory         524288               524288               bytes     
Max pending signals       139959               139959               signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Core pattern: |/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -F%F -- %E

Kernel version: Linux version 6.8.0-60-generic (buildd@lcy02-amd64-054) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #63-Ubuntu SMP PREEMPT_DYNAMIC Tue Apr 15 19:04:15 UTC 2025

Is there anything I'm missing before I raise this as a bug?

Kind regards

Derick

-- 
Derick Turner - He/Him

Managing Director
e-Learn Design Ltd | Scotland's Moodle Partner
T +44 (0)845 474 4512 | M +44 (0)7808 068 797 | www.e-learndesign.co.uk