Add AppArmor notice for Debian/Ubuntu users during server startup#5003
Open
ottok wants to merge 1 commit intoMariaDB:mainfrom
Open
Add AppArmor notice for Debian/Ubuntu users during server startup#5003ottok wants to merge 1 commit intoMariaDB:mainfrom
ottok wants to merge 1 commit intoMariaDB:mainfrom
Conversation
When MariaDB fails to start due to permission errors, users on Debian/Ubuntu might not be able to guess that AppArmor might be the cause, and they should check for AppArmor denials in the kernel audit log. Add an informational message during startup that: - Only prints when the 'mariadbd' profile is actually loaded - Includes exact commands from the Debian packaging NEWS - Provides actionable paths for local overrides - Mentions both complain and enforce modes for troubleshooting The message is printed once during normal server startup (not in help or bootstrap modes) through the existing logging infrastructure, ensuring it appears in both syslog and the error log where users will see it when troubleshooting startup failures.
grooverdan
reviewed
Apr 28, 2026
| */ | ||
| if (!opt_help && !opt_bootstrap) | ||
| { | ||
| MY_STAT stat_info; |
Member
There was a problem hiding this comment.
no point stat testing before an open. Just open and handle the ENOENT case, which we're just ignoring anyway.
| if (mariadb_profile_active) | ||
| { | ||
| sql_print_information( | ||
| "AppArmor profile 'mariadbd' is active. " |
Member
There was a problem hiding this comment.
This is rather verbose for an unconditional start case.
Could be be reduced with a link https://mariadb.com/docs/server/server-management/starting-and-stopping-mariadb/what-to-do-if-mariadb-doesnt-start#apparmor and an extended FAQ o that URL (like what selinux has)?
While it will miss a few cases does putting this as part of a fatal shutdown it useful enough?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When MariaDB fails to start due to permission errors, users on Debian/Ubuntu might not be able to guess that AppArmor might be the cause, and they should check for AppArmor denials in the kernel audit log.
Add an informational message during startup that:
The message is printed once during normal server startup (not in help or bootstrap modes) through the existing logging infrastructure, ensuring it appears in both syslog and the error log where users will see it when troubleshooting startup failures.
This has been in Debian since MariaDB 1:11.8.6-6 via https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/0a896117012567f2325675442be199180eb20a95 and no regressions have been reported. Having this upstream will pave the way to also have the actual new AppArmor profile upstream, as this notice helps users understand what might be breaking their MariaDB instance.