Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Duplicate
-
Affects Version/s: 10.0.7
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Environment:Fedora 20
Description
I stopped the server, installed with yum, moved /var/lib/mysql to /data/mysql, created a softlink
cd /var/lib
ln -s /data/mysql .
the I did the usual chown -R mysql:mysql mysql
but I still keep getting this error. This is a valid and common operation y regular mysql, to reload the data directory to another drive.
[ERROR] mysqld: Can't create/write to file '/var/lib/mysql/aria_log_control' (Errcode: 13 "Permission denied")
[ERROR] mysqld: Got error 'Can't create file' when trying to use aria control file '/var/lib/mysql/aria_log_control'
[ERROR] Plugin 'Aria' init function returned error.
[ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed.
Gliffy Diagrams
Attachments
Issue Links
- relates to
-
-
- Closed
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
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
- This file controls the state of SELinux on the system.
- SELINUX= can take one of these three values:
- enforcing - SELinux security policy is enforced.
- permissive - SELinux prints warnings instead of enforcing.
- disabled - No SELinux policy is loaded.
SELINUX=disabled - SELINUXTYPE= can take one of these two values:
- targeted - Targeted processes are protected,
- minimum - Modification of targeted policy. Only selected
processes are protected. - 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.
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.