# Initialize specified but the data directory has files in it. Aborting.

**URL:** <https://forums.percona.com/t/initialize-specified-but-the-data-directory-has-files-in-it-aborting/5032>\
**Category:** Other MySQL® Questions\
**Created:** [August 10, 2016, 4:33pm UTC](https://forums.percona.com/t/initialize-specified-but-the-data-directory-has-files-in-it-aborting/5032 "2016-08-10T16:33:25Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![cleverwise](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/cleverwise/32/1133_2.png) [@cleverwise](https://forums.percona.com/u/cleverwise)\
**Post date:** [August 10, 2016, 4:33pm UTC](https://forums.percona.com/t/initialize-specified-but-the-data-directory-has-files-in-it-aborting/5032/1 "2016-08-10T16:33:25Z")

</div>

Hello Community,

I was curious if anyone has run across this issue when trying to install Percona 5.7.13. The install from Percona yum packages for CentOS 7 goes fine, however the database won’t initialize.

When “systemctl start mysqld.service” is issued I get the following error message:

[error] --initialize specified but the data directory has files in it. Aborting.

I have repeatly deleted the mysql directory at /var/lib/mysql and rerun “systemctl start mysqld.service” and same message and no root password is generated. I can manually issue “mysqld --initialize --user=mysql --defaults-file=/etc/my.cnf” and get a root password. However the database still won’t load.

I was able to bring 5.7 up on another node a month ago with zero issues. I am not really not sure why 5.7 won’t initialize itself. The directory and all permissions are own by MySQL. My understanding is Percona thinks there is another database and thus aborts the start up process.

Yes I looked over [url][https://dev.mysql.com/doc/refman/5.7/en/data-directory-initialization-mysqld.html[/url]](https://dev.mysql.com/doc/refman/5.7/en/data-directory-initialization-mysqld.html%5B/url%5D)

Nothing on that page lead to any assistance as this version just doesn’t seem to want to initialize itself.

SELinux is off.

Anyone have any thoughts?

Thanks!

Respectfully,

Jeremy

---

<div class="post-metadata">

**Author:** ![paul.namuag](https://avatars.discourse-cdn.com/v4/letter/p/8dc957/32.png) [@paul.namuag](https://forums.percona.com/u/paul.namuag)\
**Post date:** [September 5, 2016, 8:31am UTC](https://forums.percona.com/t/initialize-specified-but-the-data-directory-has-files-in-it-aborting/5032/2 "2016-09-05T08:31:06Z")

</div>

Hi Jeremy,

Can you check the permission of /var/lib/mysql? Aside from that double check the /etc/my.cnf if you have the right path for the data dir:

$ egrep ‘data.\*dir|error.\*log’ /etc/my.cnf

Then paste the last lines from that error log.

$ tail -n50

---

<div class="post-metadata">

**Author:** ![Telford](https://avatars.discourse-cdn.com/v4/letter/t/dbc845/32.png) [@Telford](https://forums.percona.com/u/Telford)\
**Post date:** [April 30, 2017, 11:18pm UTC](https://forums.percona.com/t/initialize-specified-but-the-data-directory-has-files-in-it-aborting/5032/3 "2017-04-30T23:18:57Z")

</div>

Hi cleverwise, I got the same error when attempting to initialize a blank database with audit log items in the my.cnf file:

```auto
audit_log_policy=ALL
audit_log_rotate_on_size=64M
audit_log_rotations=10

```

Commenting out those lines allowed the initialization to complete successfully.

After the node was up and running, it was possible to shut it down, then put back the audit log configuration and then start it back up again. The node rejoined the cluster successfully, and I can see the audit.log output and also I see the audit\_log plugin is loaded. Something in the audit log configuration blocks initialization from a blank start, even though same configuration works perfectly OK once the database exists.

If anyone knows how to avoid this difficulty, by all means update me.

On close inspection I note that the error, –initialize specified but the data directory has files in it. Aborting. actually comes several seconds after an earlier error unknown variable ‘audit\_log\_policy=ALL’ which suggests there are two stages to the failure and the second stage reports a distracting error, unrelated to the real problem. I would guess that other configuration problems could cause a similar symptom here.