Fedora 16 seltsame / tmp-Berechtigungen: mysqld wird nicht gestartet

7

Ich habe MySQL auf einem brandneuen Fedora 16-Server installiert und es würde nicht starten. Dies ist die Zeile aus der Protokolldatei ( ^Gund allen):

^G/usr/libexec/mysqld: Can't create/write to file '/tmp/ibNPyIlu' (Errcode: 13)

Ich habe es angeschaut /tmp/und es hat ziemlich seltsam aussehende Berechtigungen:

drwxrwxrwt.

Warum der Punkt? chmod 1777ändert nichts. Ist dies für den Fehler verantwortlich? Was kommt als nächstes?

fedora mysql systemd bugs KateYoak
quelle

Antworten:

5

Der Punkt bedeutet, dass eine ACL (Access Control List) das übliche Unix-Berechtigungsschema überschreibt. So sieht meine aus:

$ ls -ld /tmp
drwxrwxrwt. 7 root root 4096 Apr 23 22:36 /tmp

$ getfacl /tmp
getfacl: Removing leading '/' from absolute path names
# file: tmp
# owner: root
# group: root
# flags: --t
user::rwx
group::rwx
other::rwx

Überprüfen Sie Ihr / tmp-Verzeichnis. Wenn es anders ist, korrigieren Sie es mit setfacl.

Barry Brown
quelle
Vielen Dank! Das ist neu. :-) Ich sollte mich umsehen, um mehr darüber zu erfahren. Dies war am Ende nicht die Ursache für mein Problem, aber was für ein schönes Stück Wissen!
KateYoak
Nein, der Punkt bedeutet das Gegenteil. A +bedeutet, dass erweiterte ACLs vorhanden sind.
Mikel
getfaclzeigt Ihnen, dass die Datei nur minimale ACLs hat. Siehe suse.de/~agruen/acl/linux-acls/online
Mikel
5

Fehler 13 ist wahrscheinlich ein Systemfehler 13, was bedeutet, dass die Berechtigung verweigert wurde.

$ perror 13
OS error code  13:  Permission denied

Ein Punkt bedeutet, dass die Datei einen SELinux-Kontext hat.

GNU coreutils - Welche Informationen sind aufgeführt

GNU verwendet ein '.' Zeichen zur Angabe einer Datei mit einem SELinux-Sicherheitskontext, aber keiner anderen alternativen Zugriffsmethode.

Eine Datei mit einer anderen Kombination alternativer Zugriffsmethoden ist mit einem '+' gekennzeichnet.

Sie können den SELinux-Kontext anzeigen, indem Sie ls -Zz

$ ls -dZ /tmp
drwxrwxrwt. root root system_u:object_r:tmp_t:s0       /tmp

Die nächsten Schritte sind:

  • hinein sehen /var/log/messages
  • hinein sehen /var/log/audit/audit.log
  • versuche zu laufen ausearchodersealert

Sehen:

Mikel
quelle
Siehe auch die Antwort von uther. Dies könnte die Hauptursache für Ihren speziellen Fall sein.
Mikel
2

Die Konfiguration von SELinux mit MySQL kann schwierig sein

Fedora und Red Hat verwenden SELinux (siehe in / etc / sysconfig / selinux, wenn SELINUX den Wert "Durchsetzen" hat). Ich hatte (vor 2 Jahren) MySQL auf RHEL 5 installiert und musste SELinux optimieren, damit es gut mit MySQL funktioniert.

Wenn es sich nicht um eine Verweigerung der ACL-Berechtigung handelt (wie von Barry Brown vorgeschlagen), versuchen Sie zu prüfen, ob dies Ihr Problem nicht löst, indem Sie SELINUX auf "permissive" (und einen Neustart) setzen. Wenn Sie SELinux auf "Zulässig" setzen, wird einem Prozess der angeforderte Zugriff nicht verweigert, er wird jedoch weiterhin protokolliert. Wenn also SELinux der Schuldige ist, werden Sie in den Protokollen informiert und MySQL kann trotzdem gestartet werden.

Wenn es Ihr Problem gelöst hat, Sie aber SELinux aktiviert lassen möchten, suchen Sie nach SELinux + MySQL + Fedora. Ich hatte vor 2 Jahren viele Ressourcen zu diesem Thema gefunden. Die Dinge haben sich seitdem möglicherweise geändert und hängen möglicherweise von MySQL-Versionen usw. ab. Daher kann ich Ihnen keinen besseren Rat geben, als Sie in die richtige Richtung zu weisen. :) :)

Huygens
quelle
1

Das Problem hatte nicht mit Berechtigungen zu tun - obwohl ich begeistert war, die obige Antwort zu erhalten, um meine Neugier zu befriedigen. Stattdessen stellte ich fest, dass ich nicht gelaufen war

 yum update

nach der ersten Fedora-Installation. Ich denke, der Fehler wurde irgendwo dort nach der ursprünglichen Veröffentlichung von Fedora 16 behoben. Duh.

KateYoak
quelle