mariadb.service: Main process exited, core=dumped, status=6/ABRT mariadb.service failed with result 'core-dump' Failed to start mariadb.service - MariaDB 10.11 database server Reproducible: Always Steps to Reproduce: 1. Boot/reboot Actual Results: mariadb server fails to start Expected Results: mariadb server should start Additional Information:
I've tested this, and it affects only Fedora Rawhide. When trying to reproduce on Fedora 42, it works as expected.
Here is the log of the core-dump event: 2025-05-07 3:20:24 0 [Note] Starting MariaDB 10.11.11-MariaDB source revision e69f8cae1a15e15b9e4f5e0f8497e1f17bdc81a4 server_uid f+6nbEJgvfF+m232uimNhDZHLhY= as process 10277 2025-05-07 3:20:24 0 [Note] InnoDB: Compressed tables use zlib 1.3.1.zlib-ng 2025-05-07 3:20:24 0 [Note] InnoDB: Using transactional memory 2025-05-07 3:20:24 0 [Note] InnoDB: Number of transaction pools: 1 2025-05-07 3:20:24 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions 2025-05-07 3:20:24 0 [Note] InnoDB: Using Linux native AIO 2025-05-07 3:20:24 0 [Note] InnoDB: Initializing buffer pool, total size = 128.000MiB, chunk size = 2.000MiB 2025-05-07 3:20:24 0 [Note] InnoDB: Initialized memory pressure event listener 2025-05-07 3:20:24 0 [Note] InnoDB: Completed initialization of buffer pool 2025-05-07 3:20:24 0 [Note] InnoDB: File system buffers for log disabled (block size=512 bytes) 2025-05-07 3:20:24 0 [Note] InnoDB: End of log at LSN=46980 2025-05-07 3:20:24 0 [Note] InnoDB: 128 rollback segments are active. 2025-05-07 3:20:24 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1" 2025-05-07 3:20:24 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ... 2025-05-07 3:20:24 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB. 2025-05-07 3:20:24 0 [Note] InnoDB: log sequence number 46980; transaction id 14 2025-05-07 3:20:24 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool 2025-05-07 3:20:24 0 [Note] Plugin 'FEEDBACK' is disabled. 2025-05-07 3:20:24 0 [Note] InnoDB: Buffer pool(s) load completed at 250507 3:20:24 2025-05-07 3:20:24 0 [Note] Server socket created on IP: '0.0.0.0'. 2025-05-07 3:20:24 0 [Note] Server socket created on IP: '::'. 2025-05-07 3:20:24 0 [ERROR] mariadbd: Can't create/write to file '/run/mariadb/mariadb.pid' (Errcode: 2 "No such file or directory") 2025-05-07 3:20:24 0 [ERROR] Can't start server: can't create PID file: No such file or directory terminate called without an active exception 250507 3:20:24 [ERROR] /usr/libexec/mariadbd got signal 6 ; 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: 10.11.11-MariaDB source revision: e69f8cae1a15e15b9e4f5e0f8497e1f17bdc81a4 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 0x49000 Printing to addr2line failed /usr/libexec/mariadbd(my_print_stacktrace+0x3d) [0x562c0dae725d] /usr/libexec/mariadbd(handle_fatal_signal+0x281) [0x562c0d62a001] /lib64/libc.so.6(+0x19bf0) [0x7ff1d2a28bf0] /lib64/libc.so.6(+0x73bec) [0x7ff1d2a82bec] /lib64/libc.so.6(gsignal+0x1e) [0x7ff1d2a28abe] /lib64/libc.so.6(abort+0x26) [0x7ff1d2a106d0] /lib64/libstdc++.so.6(+0x91b6) [0x7ff1d2c091b6] /lib64/libstdc++.so.6(+0x1e95c) [0x7ff1d2c1e95c] /lib64/libstdc++.so.6(_ZSt10unexpectedv+0x0) [0x7ff1d2c08d3c] /usr/libexec/mariadbd(+0x7ee59) [0x562c0d1b5e59] /lib64/libc.so.6(+0x1c231) [0x7ff1d2a2b231] /lib64/libc.so.6(+0x1c30e) [0x7ff1d2a2b30e] /usr/libexec/mariadbd(signal_hand+0x54c) [0x562c0d22983c] /usr/libexec/mariadbd(+0x740921) [0x562c0d877921] /lib64/libc.so.6(+0x71c84) [0x7ff1d2a80c84] /lib64/libc.so.6(+0xf40ac) [0x7ff1d2b030ac] 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 processes 7675 7675 processes Max open files 32183 32183 files Max locked memory 8388608 8388608 bytes Max pending signals 7675 7675 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Core pattern: |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h Kernel version: Linux version 6.15.0-0.rc3.20250425git02ddfb981de8.32.fc43.x86_64 (mockbuild@a27af863193c4fdc94a2f409a4375a42) (gcc (GCC) 15.0.1 20250418 (Red Hat 15.0.1-0), GNU ld version 2.44-3.fc43) #1 SMP PREEMPT_DYNAMIC Fri Apr 25 19:15:22 UTC 2025
It works just fine when installing the previous version `mariadb10.11-10.11.11-6.fc43` from: https://koji.fedoraproject.org/koji/buildinfo?buildID=2703926
The same issue is present in the testing version for Fedora 42: https://bodhi.fedoraproject.org/updates/FEDORA-2025-0c595b6520
This bug was introduced in commit: https://src.fedoraproject.org/rpms/mariadb10.11/c/9f34c645431d3d3308369071e4a7948d1979032f?branch=rawhide It's true we're creating the `/run/mariadb` directory at the RPM level. However, the `/run` directory is tmpfs, which means it's non-persistent and gets cleaned after reboot. The tmpfile.d configuration was making sure that after reboot, the `/run/mariadb` directory is recreated. But after it has been dropped, at the time of reboot, the `/run/mariadb` dir is removed and not recreated, thus causing this issue.
Last week I've reverted the problematic commit and pushed an update into the Rawhide: https://bodhi.fedoraproject.org/updates/FEDORA-2025-3a3aa469dc So users shouldn't experience the DB breakage anymore. The long term solution is still to be found.
I just got bitten by this on a Fedora 41 -> Fedora 42 upgrade. In other words, the *currently deployed* Mariadb in F42 is broken as-installed!
the bug is back in mariadb-3:10.11.15-1.fc42.x86_64, no /usr/lib/tmpfiles.d/mariadb.conf => mariadb crashing during startup. temp fix: 1. dnf downgrade mariadb (mariadb-3:10.11.15-1.fc42.x86_64 -> mariadb-3:10.11.11-1.fc42.x86_64) 2. cp /usr/lib/tmpfiles.d/mariadb.conf /etc/tmpfiles.d/ 3. dnf install mariadb (mariadb-3:10.11.11-1.fc42.x86_64 -> mariadb-3:10.11.15-1.fc42.x86_64) 4. reboot Now mariadb 10.11.15 starts without problems
step 3 should be: 3. dnf upgrade mariadb (mariadb-3:10.11.11-1.fc42.x86_64 -> mariadb-3:10.11.15-1.fc42.x86_64)
additional info: the same version (mariadb-10.11.15-1.fc43.x86_64) of mariadb-server, but for fc43 contains /usr/lib/tmpfiles.d/mariadb.conf: rpm -ql mariadb-server|grep tmpfiles /usr/lib/tmpfiles.d/mariadb.conf content of /usr/lib/tmpfiles.d/mariadb.conf: # Do not edit this file. # To override this, put /etc/tmpfiles.d/mariadb.conf instead. d /run/mariadb 0755 mysql mysql - # Rules for ephemeral file systems (ImageMode) d /var/lib/mysql 0755 mysql mysql - d /var/log/mariadb 0750 mysql mysql - f /var/log/mariadb/mariadb.log 0660 mysql mysql -
Fedora 43 and above branches has tmpfiles.d deletion "revert" commit: https://src.fedoraproject.org/rpms/mariadb10.11/c/810dbf2ed2b995b800284aebac5cea59abc40398?branch=rawhide But Fedora 42 branch does not have the above revert commit: https://src.fedoraproject.org/rpms/mariadb10.11/commits/f42 So currently this issue still exists on F42.
See the above f42 branch "[packaging fix for containers] Drop usage of tmpfiles.d" commit: https://src.fedoraproject.org/rpms/mariadb10.11/c/9f34c645431d3d3308369071e4a7948d1979032f?branch=f42 but revert commit does not present.
*** Bug 2430192 has been marked as a duplicate of this bug. ***
*** Bug 2430583 has been marked as a duplicate of this bug. ***
FEDORA-2026-1845afd8e8 (mariadb10.11-10.11.15-2.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2026-1845afd8e8
My apologies. Mamoru is correct, I missed this part during a F42 rebase. I prepared a BODHI update.
FEDORA-2026-1845afd8e8 has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-1845afd8e8` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-1845afd8e8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
*** Bug 2428630 has been marked as a duplicate of this bug. ***
FEDORA-2026-1845afd8e8 (mariadb10.11-10.11.15-2.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.