Fedora 20

Actually, for me it fails even earlier, on mysqld_safe level.
In my case, the problem is related to SELinux – if I setenforce Permissive, it works all right (it's not an excuse for what's happening, but an observation).

Could you please check if it solves your variation of the problem as well, so that we know it's the same thing?

Thanks.

Dear Elena
I d'ont use Selinux.
Since then, I solved it.
This is what happens. My partition is mounted in a directory at the
root, suppose it is called "/data". I did create a subdirectory
called "mysql", and gave it all the proper permissions, for example
chmod 0777 /data/mysql
But, it does not work unless you do the same with the parent
directory, /data/ . That is what I found out.
It is counter-intuitive since you may have then hundreds of
subdirectories that any user can write and read to.

Maybe you can use this information to design a more secure way of doing things.

Yours

Federico

On Mon, Dec 2, 2013 at 3:13 PM, Elena Stepanova (JIRA)

Hi Federico,

This is a bit strange, because as I said before, after disabling SELinux it worked smoothly for me just as you described initially, I didn't have to do any other steps.

• sudo systemctl stop mysqld.service

• sudo mkdir /data
• sudo mv /var/lib/mysql /data/
• cd /var/lib
• sudo ln -s /data/mysql .
• sudo chown -R mysql:mysql mysql

• sudo systemctl start mysqld.service
  (here I got a problem due to SELinux, so I set it to Permissive)

• sudo systemctl start mysqld.service
  => the server started, no errors in the log

Dear Elena
I am not using Fedora. That is the difference.
I am using the Debian 7 and regular Red Hat 6.X, licensed.
Fedora is a different OS.
I know that you are using something like Fedora because of the
systemctl command.
Do you have access to a more "traditional" Linux version?

Yours

Federico

On Mon, Dec 2, 2013 at 4:03 PM, Elena Stepanova (JIRA)

I'm only using Fedora 20 because that's what you put in the Environment field in the bug report.
Could you please fix the report then?

Thanks.

No, you are right. I found the issue on my new Fedora 20. I apologize.
If you send me your ssh public key I can give you access and we we
could reproduce the issue.
This is my selinux
cd /etc/selinux
[root@fedora20 selinux]# cat config

1. This file controls the state of SELinux on the system.
2. SELINUX= can take one of these three values:
3. enforcing - SELinux security policy is enforced.
4. permissive - SELinux prints warnings instead of enforcing.
5. disabled - No SELinux policy is loaded.
   SELINUX=disabled
6. SELINUXTYPE= can take one of these two values:
7. targeted - Targeted processes are protected,
8. minimum - Modification of targeted policy. Only selected
   processes are protected.
9. mls - Multi Level Security protection.
   SELINUXTYPE=targeted

On Mon, Dec 2, 2013 at 4:13 PM, Elena Stepanova (JIRA)

Here is my public key:
https://launchpad.net/~elenst/+sshkeys

Done
I want to send you the IP in private.
if you can please send me a private email of do instruct me as to how
to do this using JIRA
Yours
Philip

On Mon, Dec 2, 2013 at 5:10 PM, Elena Stepanova (JIRA)

Logged, took a look, sent a reply by email.
Summary: so far the described problem is not anyhow visible on the provided machine.

Hi,

As already discussed in the email, further investigation has shown that there is a real underlying problem in how /etc/init.d/mysql script treats custom basedir/datadir settings. The bug is filed on your behalf as MDEV-5378.
I suppose that the initial reconfiguration caused startup failure as explained in MDEV-5378; after that in attempts to fix the issue wrong changes were made to file/folder permissions which caused the pile of assorted access failures.

So, I will close this report as a duplicate of MDEV-5378 – although the latter is newer, it is not cluttered with irrelevant information which might be confusing.

However, I don't rule out completely that some other bugs in the mysql init script caused more access problems, so if you encounter something else that cannot be explained by MDEV-5378 description, please feel free to comment here and we'll re-open the report.

Thanks.