![mysql no se inicia al iniciar Debian (systemd), pero el inicio manual funciona](https://rvso.com/image/1540072/mysql%20no%20se%20inicia%20al%20iniciar%20Debian%20(systemd)%2C%20pero%20el%20inicio%20manual%20funciona.png)
Tengo un problema extraño con MySQL en un servidor Debian (Jessie).
Cuando se reinicia el servidor, systemd intentará iniciar mysqld, pero falla (parece que el puerto 3306 ya está usado, pero no veo por qué lo haría).
Sin embargo, si conecto SSH al servidor solo unos minutos después y lo ejecuto, sudo systemctl start mysql
será exitoso.
El problema se puede reproducir cada vez que reinicio el servidor.
¿Alguien ya ha tenido este problema o adivina qué podría impedir que MySQL se inicie correctamente? Podría agregar un retraso antes de iniciar MySQL después de reiniciar, pero me gustaría entender qué está pasando y, en realidad, ni siquiera estoy seguro de que eso solucione el problema.
Aquí está el resultado sudo systemctl status mysql -l
después del reinicio:
● mysql.service - LSB: Start and stop the mysql database server daemon
Loaded: loaded (/etc/init.d/mysql)
Active: failed (Result: exit-code) since Fri 2017-09-01 21:54:44 CEST; 1min 41s ago
Process: 581 ExecStart=/etc/init.d/mysql start (code=exited, status=1/FAILURE)
Sep 01 21:54:06 gimli systemd[1]: Starting LSB: Start and stop the mysql database server daemon...
Sep 01 21:54:44 gimli mysql[581]: Starting MySQL database server: mysqld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . failed!
Sep 01 21:54:44 gimli systemd[1]: mysql.service: control process exited, code=exited status=1
Sep 01 21:54:44 gimli systemd[1]: Failed to start LSB: Start and stop the mysql database server daemon.
Sep 01 21:54:44 gimli systemd[1]: Unit mysql.service entered failed state.
y el registro correspondiente de/var/log/mysql/error.log
170901 21:54:16 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
170901 21:54:16 [Note] Plugin 'FEDERATED' is disabled.
170901 21:54:17 InnoDB: The InnoDB memory heap is disabled
170901 21:54:17 InnoDB: Mutexes and rw_locks use GCC atomic builtins
170901 21:54:17 InnoDB: Compressed tables use zlib 1.2.8
170901 21:54:17 InnoDB: Using Linux native AIO
170901 21:54:17 InnoDB: Initializing buffer pool, size = 128.0M
170901 21:54:17 InnoDB: Completed initialization of buffer pool
170901 21:54:17 InnoDB: highest supported file format is Barracuda.
170901 21:54:22 InnoDB: Waiting for the background threads to start
170901 21:54:23 InnoDB: 5.5.57 started; log sequence number 351234412
170901 21:54:23 [Note] Server hostname (bind-address): '192.168.1.14'; port: 3306
170901 21:54:23 [Note] - '192.168.1.14' resolves to '192.168.1.14';
170901 21:54:23 [Note] Server socket created on IP: '192.168.1.14'.
170901 21:54:23 [ERROR] Can't start server: Bind on TCP/IP port: Cannot assign requested address
170901 21:54:23 [ERROR] Do you already have another mysqld server running on port: 3306 ?
170901 21:54:23 [ERROR] Aborting
170901 21:54:23 InnoDB: Starting shutdown...
170901 21:54:24 InnoDB: Shutdown completed; log sequence number 351234412
170901 21:54:24 [Note] /usr/sbin/mysqld: Shutdown complete
Sin embargo, si lo ejecuto sudo systemctl start mysql
manualmente, funciona correctamente:
170901 22:01:36 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
170901 22:01:36 [Note] Plugin 'FEDERATED' is disabled.
170901 22:01:36 InnoDB: The InnoDB memory heap is disabled
170901 22:01:36 InnoDB: Mutexes and rw_locks use GCC atomic builtins
170901 22:01:36 InnoDB: Compressed tables use zlib 1.2.8
170901 22:01:36 InnoDB: Using Linux native AIO
170901 22:01:36 InnoDB: Initializing buffer pool, size = 128.0M
170901 22:01:36 InnoDB: Completed initialization of buffer pool
170901 22:01:36 InnoDB: highest supported file format is Barracuda.
170901 22:01:36 InnoDB: Waiting for the background threads to start
170901 22:01:37 InnoDB: 5.5.57 started; log sequence number 351234412
170901 22:01:37 [Note] Server hostname (bind-address): '192.168.1.14'; port: 3306
170901 22:01:37 [Note] - '192.168.1.14' resolves to '192.168.1.14';
170901 22:01:37 [Note] Server socket created on IP: '192.168.1.14'.
170901 22:01:37 [Note] Event Scheduler: Loaded 0 events
170901 22:01:37 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.57-0+deb8u1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Debian)
Que yo sepa, el script systemd no ha sido modificado (es el que viene con el paquete mysql de Debian), y hasta donde yo sé, nunca funcionó correctamente. Se supone que el puerto 3306 no debe ser utilizado por otro proceso.
Respuesta1
Intente conectarse por SSH al servidor inmediatamente después de reiniciar y ejecutar netstat -lp | grep 3306
como root para verificar qué programa está realmente escuchando en ese puerto para poder depurar aún más el problema.
Respuesta2
Aparentemente el problema era que la interfaz de red no estaba activa en el momento en que se inicia MySQL. Probablemente esto esté relacionado con que DHCP tarda un poco.
Al menos, ahora que configuré la interfaz en IP estática, ya no observo el problema de MySQL (nuevamente, reproducible en cada inicio), así que eso resolvió el problema.
Este es el procedimiento para configurar una IP estática en Debian:
- Asegúrese de tener acceso físico a su servidor (botón de encendido, teclado, pantalla) antes de intentar alterar la red, ya que podría perder la capacidad de ssh.
- editar /etc/red/interfaces
sustituir
iface eth0 inet dhcp
por:iface eth0 inet static address 192.168.1.14 network 192.168.1.0 netmask 255.255.255.0 broadcast 192.168.1.255 gateway 192.168.1.1
- reiniciar (nota: reiniciar la red debería ser suficiente, por ejemplo con
systemctl restart networking
, pero en mi caso perdí la conexión pero no pude volver a conectarme sin reiniciar el servidor con el botón de encendido)
En este ejemplo asigno la IP estática 192.168.1.14 y la puerta de enlace 192.168.1.1
Por supuesto, esto es sólo una solución alternativa, el verdadero problema es que mysql debería esperar a que la interfaz de red esté activa, pero no conozco systemd lo suficientemente bien como para hacerlo.