Eu instalei o mysql em um novo servidor Fedora 16 e ele não seria iniciado. Esta é a linha do arquivo de log ( ^G e todos):
^G/usr/libexec/mysqld: Can't create/write to file '/tmp/ibNPyIlu' (Errcode: 13)
Eu olhei para /tmp/ e tem permissões bem estranhas:
drwxrwxrwt.
Por que o ponto? chmod 1777 não altera nada. Isso é responsável pelo erro? O que vem a seguir?
Este foi um bug com mysqld iniciando com systemd quando eles fizeram uma mudança para usar o ServicesPrivateTmp para segurança adicional. Quando você executou um yum update , o pacote mysql foi atualizado para o mysql-5.5.22-1.fc16 ou superior, o que corrigiu o problema.
O ponto significa que há uma ACL (lista de controle de acesso) substituindo o esquema usual de permissão Unix. Aqui está o meu:
$ 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
Verifique seu diretório / tmp. Se difere, use setfacl para corrigi-lo.
Erro 13 é provavelmente erro de sistema 13, o que significa permissão negada.
$ perror 13
OS error code 13: Permission denied
Um ponto significa que o arquivo tem um contexto SELinux.
GNU coreutils - Que informação está listado
GNU ls uses a ‘.’ character to indicate a file with an SELinux security context, but no other alternate access method.
A file with any other combination of alternate access methods is marked with a ‘+’ character.
Você pode exibir o contexto do SELinux executando ls -Z , por exemplo
$ ls -dZ /tmp
drwxrwxrwt. root root system_u:object_r:tmp_t:s0 /tmp
Os próximos passos são:
/var/log/messages
/var/log/audit/audit.log
ausearch ou sealert
Veja:
O SELinux pode ser complicado de configurar com o MySQL
O Fedora e a Red Hat estão usando o SELinux (veja em / etc / sysconfig / selinux se o SELINUX tiver um valor de "enforcing"). Eu tinha instalado (2 anos atrás) o MySQL no RHEL 5 e tive que ajustar o SELinux para que funcionasse bem com o MySQL.
Se não for uma negação de permissão da ACL (como sugerido por Barry Brown), tente verificar se definindo SELINUX como "permissivo" (e reinicializando) isso não resolve o problema. A configuração do SELinux como permissivo não negará a um processo o acesso solicitado, mas ele ainda será registrado. Então, se o SELinux for o culpado, você será informado nos logs e o MySQL poderá começar assim mesmo.
Se isso resolveu o seu problema, mas você quer manter o SELinux ativado, procure pelo SELinux + MySQL + Fedora, eu encontrei muitos recursos há 2 anos sobre este assunto. As coisas podem ter mudado desde então e podem depender das versões do MySQL, etc. Então, eu não posso lhe dar um conselho melhor do que apontar você na direção certa. :)
O problema não tem a ver com permissões - embora tenha ficado muito feliz em obter a resposta acima para satisfazer minha curiosidade. Em vez disso, descobri que não tinha corrido
yum update
após a instalação inicial do Fedora. Eu acho, o bug foi corrigido em algum lugar depois da versão original do Fedora 16.