ho trovato il problema (o, eventualmente, una delle I problemi). Ecco un estratto da strace su mysqld:
...
socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = 20
write(2, "2017-01-29T22:22:45.433033Z 0 [N"..., 72) = 72
setsockopt(20, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(20, SOL_IPV6, IPV6_V6ONLY, [0], 4) = 0
bind(20, {sa_family=AF_INET6, sin6_port=htons(3306), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
listen(20, 70) = 0
fcntl(20, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(20, F_SETFL, O_RDWR|O_NONBLOCK) = 0
...
accept(20, {sa_family=AF_INET6, sin6_port=htons(58332), inet_pton(AF_INET6, "::ffff:127.0.0.1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 37
rt_sigaction(SIGCHLD, {SIG_DFL, [CHLD], SA_RESTORER|SA_RESTART, 0x7f3ddeac84b0}, {SIG_DFL, [], 0}, 8) = 0
getpeername(37, {sa_family=AF_INET6, sin6_port=htons(58332), inet_pton(AF_INET6, "::ffff:127.0.0.1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0
getsockname(37, {sa_family=AF_INET6, sin6_port=htons(3306), inet_pton(AF_INET6, "::ffff:127.0.0.1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0
open("/etc/hosts.allow", O_RDONLY) = 38
fstat(38, {st_mode=S_IFREG|0644, st_size=589, ...}) = 0
read(38, "# /etc/hosts.allow: list of host"..., 4096) = 589
read(38, "", 4096) = 0
close(38) = 0
open("/etc/hosts.deny", O_RDONLY) = 38
fstat(38, {st_mode=S_IFREG|0644, st_size=704, ...}) = 0
read(38, "# /etc/hosts.deny: list of hosts"..., 4096) = 704
close(38) = 0
socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 38
connect(38, {sa_family=AF_LOCAL, sun_path="/dev/log"}, 110) = 0
sendto(38, "<36>Jan 29 14:23:08 mysqld[13052"..., 72, MSG_NOSIGNAL, NULL, 0) = 72
shutdown(20, SHUT_RDWR) = 0
close(20) = 0
poll([{fd=20, events=POLLIN}, {fd=22, events=POLLIN}], 2, -1) = 1 ([{fd=20, revents=POLLNVAL}])
accept(-1, 0x7ffe6ebd7160, 0x7ffe6ebd70fc) = -1 EBADF (Bad file descriptor)
write(2, "2017-01-29T22:23:08.109451Z 0 [E"..., 75) = 75
... rinse and repeat *REALLY* fast!
In bloccando il mio sistema con tcp_wrappers avevo inavvertitamente preso mysqld fuori sia hosts.allow e hosts.deny. Sembra che dopo aver controllato sia hosts.allow che hosts.deny mysqld arresta e chiude il socket come ci si potrebbe aspettare. Tuttavia, iniziano immediatamente a interrogare il socket (ora inesistente) per l'attività.
Ho appena fatto un altro test in cui i miei tcp_wrappers sono stati configurati correttamente. Quando mi connetto da un host autorizzato, tutto va bene; tuttavia quando mi collego da un indirizzo bloccato si verifica lo stesso problema. Sulla base di questo, ti consiglio di usare altri strumenti per proteggere mysqld e rendere la tua configurazione di tcp_wrappers più aperta rispetto al tuo firewall. Detto questo, il bug dovrebbe ancora essere corretto!
Questa correzione deve ancora superare la prova del tempo così, come al solito, YMMV. Speranza che aiuta comunque
Nick
Solo un heads-up-Sul mio sistema FC24 quando si aggiorna MariaDB con DNF, il file di systemd è stato sovrascritto e questo problema si ripresentò. – glyph
Purtroppo questa correzione non ha funzionato qui. Ho riscontrato questo errore su nuove versioni di Ubuntu 16.04 e Ubuntu 16.10 con MySQL 5.7.17. (Credo che sia necessario prima creare la cartella mysql.service ed eseguire 'systemctl daemon-reload'). – mahemoff