After MySQL Installation Service is Failing: Troubleshooting MySQL 8.0 Startup Issues

You've just installed MySQL 8.0, excited to get started with your new database server. You run sudo systemctl start mysql.service, and everything seems fine for a moment. Then you check the status and see a dreaded error: the service failed to start. Your post-installation configuration is broken, and you're staring at cryptic error messages about exit codes and dpkg dependency problems. If this sounds familiar, you're not alone—this is a surprisingly common issue, and the good news is that it's almost always fixable with systematic troubleshooting.

In this guide, we'll walk through the most common causes of MySQL 8.0 startup failures after installation and provide you with clear, actionable solutions to get your database server running smoothly.

Understanding the Error

When MySQL 8.0 fails to start during post-installation configuration, you'll typically see an error message that looks like this:

● mysql.service - MySQL Community Server
     Loaded: loaded (/usr/lib/systemd/system/mysql.service; enabled; preset: enabled)
     Active: activating (auto-restart) (Result: exit-code) since Thu 2026-04-30 10:34:48 IST; 28ms ago
    Process: 14515 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
    Process: 14523 ExecStart=/usr/sbin/mysqld (code=exited, status=1/FAILURE)
   Main PID: 14523 (code=exited, status=1/FAILURE)
     Status: "Server shutdown complete"
      Error: 22 (Invalid argument)

Let's break this down. The key line here is ExecStart=/usr/sbin/mysqld (code=exited, status=1/FAILURE). This tells us that the MySQL daemon (mysqld) process exited immediately with status 1, which is a generic failure code. The accompanying Error 22 is the clincher—it means "Invalid argument," suggesting that something the MySQL server tried to do during startup failed because of bad parameters or conflicting settings.

The dpkg error that follows is simply a downstream consequence: since the post-installation script failed, the package manager can't mark the installation as complete, leaving your MySQL package in a broken state.

Why Does This Happen?

MySQL 8.0 is stricter about its startup requirements than earlier versions. There are three main culprits behind this error:

1. Permission Issues – The mysql system user can't access the data directory or required files because ownership or permissions are incorrect.
2. Corrupt Log Files – Previous failed installation attempts left behind corrupted InnoDB redo logs or binary logs that MySQL can't replay.
3. Conflicting Configuration Settings – Your /etc/mysql/mysql.conf.d/mysqld.cnf contains invalid or incompatible settings, or uses deprecated options from MySQL 5.7.

Each of these causes a different symptom, but they all result in the same Error 22 message. The trick is figuring out which one you're dealing with.

Troubleshooting Steps

We're going to work through these causes systematically, starting with the most common and moving to the more obscure. By the end, your MySQL service should be running smoothly.

Step 1: Check Systemd Status and Logs

Before you do anything else, you need to see what MySQL is actually complaining about. The error message you see in systemctl status is usually truncated, so let's get the full picture.

Run these two commands:

sudo systemctl status mysql.service
sudo journalctl -xeu mysql.service

The first command shows you the current status of the service. Look for lines like Process: 14523 ExecStart=... to see which part of the startup process failed.

The second command shows you the detailed systemd journal for MySQL. This is where the real debugging happens. Read through the output carefully and look for lines that mention:

• Permission denied – Points to permission issues
• Can't open file – Usually means corrupt or missing log files
• Unknown variable or Invalid value – Configuration file problems
• File exists or Already in use – Port conflicts or stale lock files

Write down any specific error messages you see. They'll guide your next steps.

Step 2: Fix Permission Issues (Most Common)

Ninety percent of the time, this is your problem. During installation, MySQL needs to set up the data directory at /var/lib/mysql. If something goes wrong—like the installer crashes or you interrupt it—the directory ownership can be left in a broken state.

Check the current ownership:

ls -ld /var/lib/mysql

You should see output like:

drwx------ 33 mysql mysql 4096 Apr 30 10:34 /var/lib/mysql

If the owner is not mysql:mysql, or if the permissions don't start with 7 (or 75), you've found your problem. Fix it with:

sudo chown -R mysql:mysql /var/lib/mysql
sudo chmod -R 750 /var/lib/mysql

Here's what these commands do:

• chown -R mysql:mysql – Recursively changes the owner and group of the directory and all files inside to the mysql user and group. The -R flag means "recursive."
• chmod -R 750 – Sets permissions so the owner (mysql) has full read/write/execute (7), the group has read/execute (5), and others have no access (0).

These permissions are necessary because MySQL runs as the mysql user and needs to read and write database files. If the mysql user doesn't own these files, it can't access them, and startup fails.

After running these commands, try starting MySQL again:

sudo systemctl start mysql.service
sudo systemctl status mysql.service

If you see active (running), congratulations—you've fixed it! Skip to the verification section. If it's still failing, move on to Step 3.

Step 3: Clean Corrupt Log Files

If permissions are correct but MySQL still won't start, the problem is likely corrupt InnoDB redo logs or binary logs left over from a failed installation attempt. MySQL 8.0 uses two important log files that must be present and valid:

• ib_logfile0 and ib_logfile1 – InnoDB redo logs that record all changes to the database
• mysql-bin.000001 and similar – Binary logs (if binary logging is enabled)

If these files are corrupted, MySQL will detect the corruption during startup and refuse to proceed. The safest fix is to remove them and let MySQL recreate them fresh:

sudo systemctl stop mysql.service

Wait for the service to stop completely (this may take a few seconds). Then:

sudo mv /var/lib/mysql/ib_logfile0 /var/lib/mysql/ib_logfile0.backup
sudo mv /var/lib/mysql/ib_logfile1 /var/lib/mysql/ib_logfile1.backup

Why mv instead of rm? Because if these files are actually okay and removing them causes a bigger problem, you can recover them. Moving them is safer.

Now start MySQL again:

sudo systemctl start mysql.service
sudo systemctl status mysql.service

When MySQL starts, it will notice the redo logs are missing and recreate them automatically. If you see active (running), the problem was indeed corrupt logs. If it's still failing, try Step 4.

Step 4: Review and Fix Configuration Settings

If permissions are fine and the logs are clean, the issue is almost certainly your MySQL configuration file. MySQL 8.0 removed support for several options that were common in MySQL 5.7 and earlier versions.

Open the main MySQL configuration file:

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Look for any of these deprecated or problematic settings and remove or comment them out (add a # at the start of the line):

Deprecated options in MySQL 8.0:

# Remove these if present:
skip-name-resolve           # No longer needed; use skip_name_resolve instead
log-bin=mysql-bin           # Use binlog filename or leave blank
relay-log=mysql-relay-bin   # Use relay_log filename or leave blank
default-storage-engine=InnoDB  # InnoDB is the default; this line is optional
innodb_buffer_pool_size=...    # Only set if you know what you're doing

Common problem settings:

# If you see these, they may cause issues:
binlog_format=STATEMENT     # Use ROW or MIXED instead
sql-mode=...                # Check if it contains deprecated modes

Here's a minimal, safe configuration for a development MySQL 8.0 server:

[mysqld]
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
datadir         = /var/lib/mysql
log-error       = /var/log/mysql/error.log

# MySQL 8.0 defaults
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci

If your mysqld.cnf has a lot of customization, the safest approach is to:

1. Make a backup of the current file: sudo cp /etc/mysql/mysql.conf.d/mysqld.cnf /etc/mysql/mysql.conf.d/mysqld.cnf.backup
2. Replace it with the minimal config above
3. Test if MySQL starts
4. If it does, gradually add back your custom settings one by one, testing after each change

To save your changes in nano, press Ctrl+X, then Y, then Enter.

Now try starting MySQL:

sudo systemctl start mysql.service
sudo systemctl status mysql.service

If this fixes it, you found a configuration conflict. If MySQL is still failing, move on to the final step.

Step 5: Reinstall MySQL (Last Resort)

If you've made it this far without success, the cleanest solution is to completely remove MySQL and reinstall it fresh. Before you do this, make sure you back up any important data:

sudo mysqldump -u root -p --all-databases > /home/$(whoami)/mysql_backup.sql

Enter your MySQL root password when prompted. This exports all your databases to a file you can restore later.

Now, remove MySQL completely:

sudo apt-get remove mysql-server mysql-server-8.0 mysql-client
sudo apt-get autoremove
sudo apt-get autoclean

This removes the MySQL packages but leaves the data directory intact (by default). If you want a completely clean slate, also run:

sudo rm -rf /var/lib/mysql

Warning: This deletes all your databases. Only do this if you've already backed them up.

Now reinstall MySQL:

sudo apt-get update
sudo apt-get install mysql-server-8.0

During installation, you'll be prompted to set a root password. Choose a secure password and remember it. The installer should complete without errors this time.

After installation, verify it's running:

sudo systemctl status mysql.service

If it's still failing, there may be a system-level issue beyond the scope of this guide. Check /var/log/mysql/error.log for clues:

sudo tail -50 /var/log/mysql/error.log

Verification and Prevention

Confirm MySQL is Running

Let's make sure everything is working. Check the service status:

sudo systemctl status mysql.service

You should see:

● mysql.service - MySQL Community Server
     Loaded: loaded (/usr/lib/systemd/system/mysql.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-04-30 10:45:22 IST; 2min 15s ago

The key phrase here is active (running). If you see that, MySQL is ready to use.

Now test the connection by logging in:

sudo mysql -u root -p

Enter your root password. You should see the MySQL prompt:

mysql>

Run a simple query to confirm everything is working:

SELECT version();

You should see output showing your MySQL version (e.g., 8.0.35-0ubuntu0.22.04.1). Type exit; to quit.

Enable Auto-Start

If you've fixed the startup issue, you'll want to make sure MySQL starts automatically when your system boots. Enable this with:

sudo systemctl enable mysql.service

Verify it's enabled:

sudo systemctl is-enabled mysql.service

You should see enabled. If you ever want to disable auto-start, run:

sudo systemctl disable mysql.service

Best Practices to Prevent This in the Future

1. Always use the official MySQL repository. This ensures you're getting a properly packaged version for your OS. Avoid third-party or outdated repositories.

2. Test on non-production first. If you're deploying MySQL in a production environment, always test the installation and configuration on a development machine first.

3. Keep your configuration simple. The more settings you customize, the higher the chance of conflicts. Start with defaults and add only what you need.

4. Monitor file permissions monthly. Use a cron job or systemd timer to periodically check that /var/lib/mysql is owned by mysql:mysql with correct permissions.

5. Back up before major updates. Always export your databases before upgrading MySQL:
   

   sudo mysqldump -u root -p --all-databases > mysql_backup_$(date +%Y%m%d).sql

1. Keep MySQL logs accessible. The error.log at /var/log/mysql/error.log is your best friend. Check it regularly and keep it readable.

Conclusion

MySQL 8.0's strict startup requirements can be frustrating when you first encounter them, but they exist for a reason—safety and stability. The Error 22 (Invalid argument) you're seeing is MySQL's way of saying "something's not right," and now you have the tools to figure out what.

In most cases, fixing file permissions will solve your problem immediately. If not, corrupt log files or configuration conflicts are the next likely culprits. By working through these steps systematically—starting with the easiest and moving to the nuclear option of reinstalling—you'll identify and fix the issue without losing any data.

The key is to always check the logs first. That journalctl output tells you exactly what went wrong, and from there, the fix is usually straightforward. Don't be discouraged if the first solution doesn't work; database administration is often a process of elimination.

Once you get MySQL running, take a moment to set up those preventative measures—enable auto-start, keep backups, and monitor permissions. Your future self will thank you when you never have to debug this again.

Good luck, and happy querying!

Word Count: 1,847 words

Estimated Reading Time: 8–10 minutes