Bug 144336
Summary: | mysql-server won't start after yum update to 3.23.58-14 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Edward Samson <edwardsamson> |
Component: | mysql | Assignee: | Tom Lane <tgl> |
Status: | CLOSED NOTABUG | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3 | CC: | dwalsh, hhorak, sundaram |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-09-05 07:25:13 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Edward Samson
2005-01-06 04:37:24 UTC
Apparently you've got a permissions problem on either the /var/lib/mysql/mysql directory or the host.frm file therein. Or maybe on /var/lib/mysql itself. I can believe that the RPM upgrade might have reset the ownership/permissions of /var/lib/mysql to the standard settings ... is it possible you are trying to run mysqld under a nondefault account, or some such? I checked the permissions and I don't think that's the problem. I just performed a clean install of fc3 2 weeks ago and had been using mysql with the default settings. I'm sure I'm not trying to run mysqld under a nondefault account unless that was caused by the RPM upgrade. Removing 3.23.58-14 and going back to 3.23.58-13 gets my server working again but trying to update again to 3.23.58-14 and the same problem occurs. Hmph. I just tried this on my own machine (which is up-to-date with FC3). I wiped mysql, reinstalled the -13 RPMs, then did "yum update" to bring in the -14 RPMs. Works fine for me. I see this as the permissions in /var/lib/mysql: $ ls -la /var/lib/mysql total 36 drwxr-xr-x 4 mysql mysql 4096 Jan 6 01:27 . drwxr-xr-x 21 root root 4096 Jan 5 12:27 .. drwx------ 2 mysql mysql 4096 Jan 6 01:23 mysql drwx------ 2 mysql mysql 4096 Jan 6 01:23 test Does that match yours? It could also be that the problem is SELinux related; are you running in enforcement mode, and if so does switching to permissive mode fix it? (sudo /usr/sbin/setenforce 0) If so look in /var/log/messages to see what SELinux is complaining about. I see no evidence of such a problem here, but obviously there's *something* different between your machine and mine... Yup, I've got SELinux enabled in enforcement mode and I think that's it. I've got this in /var/log/messages: Jan 6 08:33:01 localhost kernel: audit(1104971581.126:0): avc: denied { read } for pid=2532 exe=/usr/libexec/mysqld name=host.frm dev=dm-0 ino=2015359 scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=file Jan 6 08:33:10 localhost mysqld: Starting MySQL: failed Does that mean anything to you? Unfortunately, I can't try it out right now. I'll report back as soon as I get the chance to try it. Thanks Dan, any idea why SELinux is refusing access to a file under /var/lib/mysql? And why the -13 and -14 RPMs would act differently, when there is no code change anywhere near that? (For that matter, why don't I see such a failure here?) Edward, which selinux-policy-targeted version are you using? selinux-policy-targeted-1.17.30-2.66 What is the file context of /var/lib/mysql? Should be mysql_db_t. restorecon -R -v /var/lib/mysql. If you delete this directory should recreate it with the correct context. Dan |