Start MariaDB Safely with mysqld_safe

You will finish with a controlled way to start the MariaDB server using mysqld_safe, find the messages that explain a failed start, and keep its option-file behaviour predictable. On this Ubuntu installation, mysqld_safe is the compatibility symlink to mariadbd-safe from MariaDB Server 10.11.14, supplied by the mariadb-server package.

Allow about fifteen minutes for a routine start and verification. You need a shell, an initialised MariaDB data directory, and an account that can read the installation and data paths. Starting an already managed production instance can interrupt service or create a second server process, so first establish who owns the instance.

1. Confirm which wrapper you are using

These are ordinary, read-only checks. They do not start MariaDB and do not need elevated privileges:

$ command -v mysqld_safe
/usr/bin/mysqld_safe
$ readlink -f "$(command -v mysqld_safe)"
/usr/bin/mariadbd-safe
$ dpkg-query -W -f='${Package} ${Version}\n' mariadb-server
mariadb-server 1:10.11.14-0ubuntu0.24.04.1

The names are historical. The installed manual describes mariadbd-safe as the MariaDB server startup script and says that mysqld_safe is now a symlink to it. Use the name already used by your service documentation, but expect the same wrapper here.

Checkpoint: ask the installed wrapper for its accepted options before copying an example from a different MariaDB release:

$ mysqld_safe --help
Usage: /usr/bin/mysqld_safe [OPTIONS]

Options not understood by the wrapper are passed to the server when supplied on the command line. Options unknown to the wrapper are ignored when placed in its option-file groups, which makes a typo in configuration particularly easy to miss.

2. Identify the instance before starting it

Do not start a second copy over an existing service. Check the process list and the likely system service first:

$ pgrep -a -f '(^|/)(mariadbd|mysqld)( |$)' || true
$ systemctl status mariadb --no-pager

The first command may print nothing when no server is running. The service status may show a different unit name on another installation. If a systemd unit is already responsible for MariaDB, use that unit's configuration and logs rather than launching an unmanaged second server with mysqld_safe.

If the server is stopped and this is a deliberate manual start, find the paths you will use. Replace the placeholders below with real paths from your installation:

$ test -x /usr/sbin/mariadbd && echo 'server executable exists'
server executable exists
$ test -d /var/lib/mysql && echo 'data directory exists'
data directory exists

Do not create a new data directory as part of this guide. Initialising one is a separate operation with its own ownership and recovery decisions.

3. Choose an option-file strategy

The wrapper reads the [mysqld], [server], [mysqld_safe] and [mariadb_safe] groups. It also accepts the older [safe_mysqld] group for compatibility. Put server settings such as datadir in [mysqld]; put wrapper settings such as log-error or no-auto-restart where the installed configuration expects them.

For a one-off test, an extra file is less surprising than editing the packaged configuration:

[mysqld]
datadir=/var/lib/mysql

[mysqld_safe]
log-error=/var/log/mysql/mariadb-manual.err

Save that as /path/to/mariadb-test.cnf only after checking that the directory and file permissions match the account that will run the server. The file must be readable by the launching account. Treat it as sensitive: database paths and startup settings are operational information.

There is a positional trap here. --defaults-file and --defaults-extra-file must be the first command-line option. This is correct:

$ mysqld_safe --defaults-file=/path/to/mariadb-test.cnf --no-auto-restart

This is not equivalent, because the named file comes too late:

$ mysqld_safe --no-auto-restart --defaults-file=/path/to/mariadb-test.cnf

--defaults-file replaces the usual option-file search. --defaults-extra-file adds one file to the normal search. --no-defaults also has to be first and disables option files, which is useful when you are proving that an unexpected setting came from configuration rather than the command line.

4. Start a stopped server deliberately

Starting the server changes system state and may make the database available to clients. Check your maintenance window, backup position and service ownership before running this step. Use an account that can run the server with the intended MariaDB system user; do not use root as a shortcut for unknown permissions.

For a normal installation whose executable and data directory are discoverable, a simple start is:

$ mysqld_safe --datadir=/var/lib/mysql --user=mysql &

The wrapper monitors the server and can restart it after an error. The command prompt returning does not prove that the server is accepting connections. --no-auto-restart or its aliases --nowatch and --no-watch make the wrapper exit after starting the server, but that does not turn the server itself into a foreground test process.

Use --ledir when the server executable is not in the directory the wrapper found, and --mysqld when you need to name the server program explicitly. Use --socket, --port and --pid-file only when those values match the server configuration and your client checks. A TCP port below 1024 requires the server to be started by root, so prefer a normal unprivileged port and the MariaDB service account.

5. Verify the start and read the right log

Run these checks from a second shell:

$ pgrep -a -f '(^|/)(mariadbd|mysqld)( |$)'
$ mariadb-admin --socket=/path/to/mysql.sock ping
mariadbd is alive

The socket path is installation-specific. Replace it with the value from your option files or the startup command. If you configured --port, use the corresponding host and port instead. A successful client check is stronger evidence than a wrapper message alone.

By default this installation's wrapper uses --skip-syslog, so messages go to an error log. --log-error=/path/to/server.err selects a named file. --syslog sends messages through logger; if both --syslog and --log-error are supplied, the named error file takes precedence. Inspect the configured destination immediately when the ping fails:

$ tail -n 80 /path/to/server.err

Look for path, permission, address-in-use and option parsing errors. Do not repeatedly restart a failing server while ignoring the log: the wrapper's restart behaviour can turn one configuration error into a noisy loop.

6. Stop, undo and recover safely

Do not kill a MariaDB process as the first response. Ask the service manager to stop a managed instance. For a deliberately manual instance, use the normal MariaDB administrative shutdown method with suitable credentials, then confirm that the process and socket have gone. Killing the process can interrupt transactions and may require crash recovery.

If you changed only a temporary option file, stop the manual instance, remove that file using your normal change-control process, and restore the previous service start configuration. If the start failed, remove no data files and do not delete the error log until the failure has been recorded. If --open-files-limit is used, the manual says it needs a root start to work properly; solve the limit through the service manager and operating-system limits rather than casually running the whole database as root.