[mysqld] failed to start on boot [résolu]
Publié : sam. 15 sept. 2018, 19:24
Bonjour,
Ce matin, lors de la mise à jour, j'ai vu passer mariadb, depuis mariadb ne démarre plus au boot.
Le démarrage du serveur est très long :
Le status :
Un
Auriez-vous des pistes ?
Edit :
Ce matin, lors de la mise à jour, j'ai vu passer mariadb, depuis mariadb ne démarre plus au boot.
Le démarrage du serveur est très long :
Code : Tout sélectionner
$ systemd-analyze blame
4min 31.126s mariadb.service
837ms lvm2-monitor.service
755ms dev-vda1.device
280ms systemd-journal-flush.service
277ms systemd-networkd.service
235ms systemd-logind.service
221ms systemd-udev-trigger.service
194ms systemd-udevd.service
189ms systemd-journald.service
166ms sys-kernel-config.mount
164ms sys-kernel-debug.mount
159ms dev-hugepages.mount
154ms systemd-tmpfiles-setup-dev.service
154ms tmp.mount
119ms dev-mqueue.mount
113ms systemd-tmpfiles-clean.service
112ms user@1000.service
99ms systemd-remount-fs.service
88ms pacman-reanimation.service
76ms systemd-random-seed.service
63ms systemd-sysctl.service
54ms kmod-static-nodes.service
45ms systemd-user-sessions.service
39ms systemd-tmpfiles-setup.service
28ms systemd-update-utmp.service
20ms proc-sys-fs-binfmt_misc.mount
Code : Tout sélectionner
$ systemctl status mysqld.service
● mariadb.service - MariaDB 10.1.36 database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
Active: failed (Result: timeout) since Sat 2018-09-15 19:11:21 CEST; 3min 47s ago
Docs: man:mysqld(8)
https://mariadb.com/kb/en/library/systemd/
Process: 284 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= || VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ] && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
Process: 279 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
Main PID: 363
Tasks: 0 (limit: 2323)
Memory: 23.3M
CGroup: /system.slice/mariadb.service
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: /usr/bin/mysqld(+0x809dff)[0xa384595adff]
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: /usr/bin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x6d)[0xa38456e68cd]
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: /usr/bin/mysqld(+0x412e38)[0xa3845563e38]
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: /usr/bin/mysqld(_Z11plugin_initPiPPci+0x983)[0xa3845565003]
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: /usr/bin/mysqld(+0x36d3c0)[0xa38454be3c0]
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: /usr/bin/mysqld(_Z11mysqld_mainiPPc+0x1b2e)[0xa38454c1e0e]
sept. 15 19:12:59 vps301757.ovh.net mysqld[363]: /usr/lib/libc.so.6(__libc_start_main+0xf3)[0x62dce6578223]
sept. 15 19:12:59 vps301757.ovh.net mysqld[363]: /usr/bin/mysqld(_start+0x2e)[0xa38454b592e]
sept. 15 19:12:59 vps301757.ovh.net mysqld[363]: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
sept. 15 19:12:59 vps301757.ovh.net mysqld[363]: information that should help you find out what is causing the crash.
Code : Tout sélectionner
$ journalctl -p err
sept. 15 19:11:21 vps301757.ovh.net systemd[1]: Failed to start MariaDB 10.1.36 database server.
sept. 15 19:13:01 vps301757.ovh.net systemd-coredump[387]: Process 363 (mysqld) of user 89 dumped core.
Stack trace of thread 363:
#0 0x000062dce658c07b kill (libc.so.6)
#1 0x00000a38456e461c handle_fatal_signal (mysqld)
#2 0x000062dce6a3e3c0 __restore_rt (libpthread.so.0)
#3 0x000062dce658bd7f raise (libc.so.6)
#4 0x000062dce6576672 abort (libc.so.6)
#5 0x00000a3845ade189 n/a (mysqld)
#6 0x00000a3845ad5880 n/a (mysqld)
#7 0x00000a3845a4b321 n/a (mysqld)
#8 0x00000a384595adff n/a (mysqld)
#9 0x00000a38456e68cd _Z24ha_initialize_handlertonP13st_plugin_int (mysqld)
#10 0x00000a3845563e38 n/a (mysqld)
#11 0x00000a3845565003 _Z11plugin_initPiPPci (mysqld)
#12 0x00000a38454be3c0 n/a (mysqld)
#13 0x00000a38454c1e0e _Z11mysqld_mainiPPc (mysqld)
#14 0x000062dce6578223 __libc_start_main (libc.so.6)
#15 0x00000a38454b592e _start (mysqld)
Stack trace of thread 364:
#0 0x000062dce6a39e5b pthread_cond_timedwait@@GLIBC_2.3.2 (libpthread.so.0)
#1 0x00000a3845b96f33 n/a (mysqld)
#2 0x000062dce6a33a9d start_thread (libpthread.so.0)
#3 0x000062dce664fa43 __clone (libc.so.6)
Stack trace of thread 365:
#0 0x000062dce6a39e5b pthread_cond_timedwait@@GLIBC_2.3.2 (libpthread.so.0)
#1 0x00000a3845879460 n/a (mysqld)
#2 0x00000a38458719fc n/a (mysqld)
#3 0x000062dce6a33a9d start_thread (libpthread.so.0)
#4 0x000062dce664fa43 __clone (libc.so.6)
Stack trace of thread 366:
#0 0x000062dce664a40d syscall (libc.so.6)
#1 0x000062dce70077aa n/a (libaio.so.1)
#2 0x00000a38459cdbf1 n/a (mysqld)
#3 0x00000a3845b0750c n/a (mysqld)
#4 0x00000a3845a46070 n/a (mysqld)
#5 0x000062dce6a33a9d start_thread (libpthread.so.0)
#6 0x000062dce664fa43 __clone (libc.so.6)
Stack trace of thread 367:
#0 0x000062dce664a40d syscall (libc.so.6)
#1 0x000062dce70077aa n/a (libaio.so.1)
#2 0x00000a38459cdbf1 n/a (mysqld)
#3 0x00000a3845b0750c n/a (mysqld)
#4 0x00000a3845a46070 n/a (mysqld)
#5 0x000062dce6a33a9d start_thread (libpthread.so.0)
#6 0x000062dce664fa43 __clone (libc.so.6)
Stack trace of thread 368:
#0 0x000062dce664a40d syscall (libc.so.6)
#1 0x000062dce70077aa n/a (libaio.so.1)
#2 0x00000a38459cdbf1 n/a (mysqld)
#3 0x00000a3845b0750c n/a (mysqld)
#4 0x00000a3845a46070 n/a (mysqld)
#5 0x000062dce6a33a9d start_thread (libpthread.so.0)
#6 0x000062dce664fa43 __clone (libc.so.6)
Stack trace of thread 369:
#0 0x000062dce664a40d syscall (libc.so.6)
#1 0x000062dce70077aa n/a (libaio.so.1)
#2 0x00000a38459cdbf1 n/a (mysqld)
#3 0x00000a3845b0750c n/a (mysqld)
#4 0x00000a3845a46070 n/a (mysqld)
#5 0x000062dce6a33a9d start_thread (libpthread.so.0)
#6 0x000062dce664fa43 __clone (libc.so.6)
Stack trace of thread 370:
#0 0x000062dce664a40d syscall (libc.so.6)
#1 0x000062dce70077aa n/a (libaio.so.1)
#2 0x00000a38459cdbf1 n/a (mysqld)
#3 0x00000a3845b0750c n/a (mysqld)
#4 0x00000a3845a46070 n/a (mysqld)
#5 0x000062dce6a33a9d start_thread (libpthread.so.0)
#6 0x000062dce664fa43 __clone (libc.so.6)
Stack trace of thread 371:
#0 0x000062dce664a40d syscall (libc.so.6)
#1 0x000062dce70077aa n/a (libaio.so.1)
#2 0x00000a38459cdbf1 n/a (mysqld)
#3 0x00000a3845b0750c n/a (mysqld)
#4 0x00000a3845a46070 n/a (mysqld)
#5 0x000062dce6a33a9d start_thread (libpthread.so.0)
#6 0x000062dce664fa43 __clone (libc.so.6)
Stack trace of thread 372:
#0 0x000062dce664a40d syscall (libc.so.6)
#1 0x000062dce70077aa n/a (libaio.so.1)
#2 0x00000a38459cdbf1 n/a (mysqld)
#3 0x00000a3845b0750c n/a (mysqld)
#4 0x00000a3845a46070 n/a (mysqld)
#5 0x000062dce6a33a9d start_thread (libpthread.so.0)
#6 0x000062dce664fa43 __clone (libc.so.6)
Stack trace of thread 373:
#0 0x000062dce664a40d syscall (libc.so.6)
#1 0x000062dce70077aa n/a (libaio.so.1)
#2 0x00000a38459cdbf1 n/a (mysqld)
#3 0x00000a3845b0750c n/a (mysqld)
#4 0x00000a3845a46070 n/a (mysqld)
#5 0x000062dce6a33a9d start_thread (libpthread.so.0)
#6 0x000062dce664fa43 __clone (libc.so.6)
Stack trace of thread 374:
#0 0x000062dce664a40d syscall (libc.so.6)
#1 0x000062dce70077aa n/a (libaio.so.1)
#2 0x00000a38459cdbf1 n/a (mysqld)
#3 0x00000a3845b0750c n/a (mysqld)
#4 0x00000a3845a46070 n/a (mysqld)
#5 0x000062dce6a33a9d start_thread (libpthread.so.0)
#6 0x000062dce664fa43 __clone (libc.so.6)
Stack trace of thread 375:
#0 0x000062dce664a40d syscall (libc.so.6)
#1 0x000062dce70077aa n/a (libaio.so.1)
#2 0x00000a38459cdbf1 n/a (mysqld)
#3 0x00000a3845b0750c n/a (mysqld)
#4 0x00000a3845a46070 n/a (mysqld)
#5 0x000062dce6a33a9d start_thread (libpthread.so.0)
#6 0x000062dce664fa43 __clone (libc.so.6)
Stack trace of thread 379:
#0 0x000062dce6a39e5b pthread_cond_timedwait@@GLIBC_2.3.2 (libpthread.so.0)
#1 0x00000a38459d042f n/a (mysqld)
#2 0x00000a3845a41cec n/a (mysqld)
#3 0x000062dce6a33a9d start_thread (libpthread.so.0)
#4 0x000062dce664fa43 __clone (libc.so.6)
Un
sudo systemctl start mysqld
démarre correctement mariadb.Auriez-vous des pistes ?
Edit :
Code : Tout sélectionner
sept. 15 19:06:50 vps301757.ovh.net systemd[1]: Starting MariaDB 10.1.36 database server...
sept. 15 19:06:51 vps301757.ovh.net mysqld[363]: 2018-09-15 19:06:51 108700891013056 [Note] Using unique option prefix 'character_set_client' is error-prone and can break in the future. Please use the full name 'character-set-client-handshake' instead.
sept. 15 19:06:51 vps301757.ovh.net mysqld[363]: 2018-09-15 19:06:51 108700891013056 [Warning] /usr/bin/mysqld: ignoring option '--character-set-client-handshake' due to invalid value 'utf8'
sept. 15 19:06:51 vps301757.ovh.net mysqld[363]: 2018-09-15 19:06:51 108700891013056 [Note] /usr/bin/mysqld (mysqld 10.1.36-MariaDB) starting as process 363 ...
sept. 15 19:06:51 vps301757.ovh.net mysqld[363]: 2018-09-15 19:06:51 108700891013056 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.
sept. 15 19:06:51 vps301757.ovh.net mysqld[363]: 2018-09-15 19:06:51 108700891013056 [Note] InnoDB: Using mutexes to ref count buffer pool pages
sept. 15 19:06:51 vps301757.ovh.net mysqld[363]: 2018-09-15 19:06:51 108700891013056 [Note] InnoDB: The InnoDB memory heap is disabled
sept. 15 19:06:51 vps301757.ovh.net mysqld[363]: 2018-09-15 19:06:51 108700891013056 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
sept. 15 19:06:51 vps301757.ovh.net mysqld[363]: 2018-09-15 19:06:51 108700891013056 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
sept. 15 19:06:51 vps301757.ovh.net mysqld[363]: 2018-09-15 19:06:51 108700891013056 [Note] InnoDB: Compressed tables use zlib 1.2.11
sept. 15 19:06:51 vps301757.ovh.net mysqld[363]: 2018-09-15 19:06:51 108700891013056 [Note] InnoDB: Using Linux native AIO
sept. 15 19:06:51 vps301757.ovh.net mysqld[363]: 2018-09-15 19:06:51 108700891013056 [Note] InnoDB: Using SSE crc32 instructions
sept. 15 19:06:51 vps301757.ovh.net mysqld[363]: 2018-09-15 19:06:51 108700891013056 [Note] InnoDB: Initializing buffer pool, size = 128.0M
sept. 15 19:06:51 vps301757.ovh.net mysqld[363]: 2018-09-15 19:06:51 108700891013056 [Note] InnoDB: Completed initialization of buffer pool
sept. 15 19:08:21 vps301757.ovh.net systemd[1]: mariadb.service: Start operation timed out. Terminating.
sept. 15 19:09:51 vps301757.ovh.net systemd[1]: mariadb.service: State 'stop-sigterm' timed out. Skipping SIGKILL.
sept. 15 19:11:21 vps301757.ovh.net systemd[1]: mariadb.service: State 'stop-final-sigterm' timed out. Skipping SIGKILL. Entering failed mode.
sept. 15 19:11:21 vps301757.ovh.net systemd[1]: mariadb.service: Failed with result 'timeout'.
sept. 15 19:11:21 vps301757.ovh.net systemd[1]: Failed to start MariaDB 10.1.36 database server.
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: 2018-09-15 19:12:58 108700891013056 [Note] InnoDB: Highest supported file format is Barracuda.
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: 2018-09-15 19:12:58 108700891013056 [Note] InnoDB: Read redo log up to LSN=685190144
sept. 15 19:12:58 vps301757.ovh.net systemd[1]: mariadb.service: Got notification message from PID 363, but reception only permitted for main PID which is currently not known
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: 2018-09-15 19:12:58 108700891013056 [ERROR] mysqld: Can't create/write to file '/tmp/ib5gVV6N' (Errcode: 2 "No such file or directory")
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: 2018-09-15 19:12:58 62dce5fedfc0 InnoDB: Error: unable to create temporary file; errno: 2
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: 2018-09-15 19:12:58 62dce5fedfc0 InnoDB: Assertion failure in thread 108700891013056 in file dict0dict.cc line 1089
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: InnoDB: Failing assertion: dict_foreign_err_file
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: InnoDB: We intentionally generate a memory trap.
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: InnoDB: If you get repeated assertion failures or crashes, even
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: InnoDB: immediately after the mysqld startup, there may be
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: InnoDB: corruption in the InnoDB tablespace. Please refer to
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: InnoDB: about forcing recovery.
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: 180915 19:12:58 [ERROR] mysqld got signal 6 ;
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: This could be because you hit a bug. It is also possible that this binary
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: or one of the libraries it was linked against is corrupt, improperly built,
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: or misconfigured. This error can also be caused by malfunctioning hardware.
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: To report this bug, see https://mariadb.com/kb/en/reporting-bugs
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: We will try our best to scrape up some info that will hopefully help
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: diagnose the problem, but since we have already crashed,
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: something is definitely wrong and this may fail.
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: Server version: 10.1.36-MariaDB
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: key_buffer_size=16777216
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: read_buffer_size=262144
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: max_used_connections=0
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: max_threads=153
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: thread_count=0
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: It is possible that mysqld could use up to
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 137052 K bytes of memory
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: Hope that's ok; if not, decrease some variables in the equation.
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: Thread pointer: 0x0
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: Attempting backtrace. You can use the following information to find out
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: where mysqld died. If you see no messages after this, something went
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: terribly wrong...
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: stack_bottom = 0x0 thread_stack 0x48400
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: /usr/bin/mysqld(my_print_stacktrace+0x2f)[0xa3845b92bdf]
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: /usr/bin/mysqld(handle_fatal_signal+0x586)[0xa38456e4756]
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: sigaction.c:0(__restore_rt)[0x62dce6a3e3c0]
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: :0(__GI_raise)[0x62dce658bd7f]
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: :0(__GI_abort)[0x62dce6576672]
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: /usr/bin/mysqld(+0x98d189)[0xa3845ade189]
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: /usr/bin/mysqld(+0x984880)[0xa3845ad5880]
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: /usr/bin/mysqld(+0x8fa321)[0xa3845a4b321]
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: /usr/bin/mysqld(+0x809dff)[0xa384595adff]
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: /usr/bin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x6d)[0xa38456e68cd]
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: /usr/bin/mysqld(+0x412e38)[0xa3845563e38]
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: /usr/bin/mysqld(_Z11plugin_initPiPPci+0x983)[0xa3845565003]
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: /usr/bin/mysqld(+0x36d3c0)[0xa38454be3c0]
sept. 15 19:12:58 vps301757.ovh.net mysqld[363]: /usr/bin/mysqld(_Z11mysqld_mainiPPc+0x1b2e)[0xa38454c1e0e]
sept. 15 19:12:59 vps301757.ovh.net mysqld[363]: /usr/lib/libc.so.6(__libc_start_main+0xf3)[0x62dce6578223]
sept. 15 19:12:59 vps301757.ovh.net mysqld[363]: /usr/bin/mysqld(_start+0x2e)[0xa38454b592e]
sept. 15 19:12:59 vps301757.ovh.net mysqld[363]: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
sept. 15 19:12:59 vps301757.ovh.net mysqld[363]: information that should help you find out what is causing the crash