My YunoHost server
Hardware: Olimex LIME2
YunoHost version: 3.5.2.2
I have access to my server : Through SSH | through the webadmin
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : no
Description of my issue
Probably after an unexpected restart of my server, the mysqld service won’t start. This is what I have in the syslog:
Apr 21 16:55:46 ynh systemd[1]: Starting MariaDB 10.1.37 database server...
Apr 21 16:55:47 ynh mysqld[27663]: 2019-04-21 16:55:47 3063290672 [Warning] option 'table_open_cache': unsigned value 4 adjusted to 10
Apr 21 16:55:47 ynh mysqld[27663]: 2019-04-21 16:55:47 3063290672 [Note] /usr/sbin/mysqld (mysqld 10.1.37-MariaDB-0+deb9u1) starting as process 27663 ...
Apr 21 16:55:47 ynh mysqld[27663]: 2019-04-21 16:55:47 3063290672 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase $
Apr 21 16:55:47 ynh mysqld[27663]: 2019-04-21 16:55:47 3063290672 [Note] InnoDB: Using mutexes to ref count buffer pool pages
Apr 21 16:55:47 ynh mysqld[27663]: 2019-04-21 16:55:47 3063290672 [Note] InnoDB: The InnoDB memory heap is disabled
Apr 21 16:55:47 ynh mysqld[27663]: 2019-04-21 16:55:47 3063290672 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
Apr 21 16:55:47 ynh mysqld[27663]: 2019-04-21 16:55:47 3063290672 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
Apr 21 16:55:47 ynh mysqld[27663]: 2019-04-21 16:55:47 3063290672 [Note] InnoDB: Compressed tables use zlib 1.2.8
Apr 21 16:55:47 ynh mysqld[27663]: 2019-04-21 16:55:47 3063290672 [Note] InnoDB: Using Linux native AIO
Apr 21 16:55:47 ynh mysqld[27663]: 2019-04-21 16:55:47 3063290672 [Note] InnoDB: Using generic crc32 instructions
Apr 21 16:55:47 ynh mysqld[27663]: 2019-04-21 16:55:47 3063290672 [Note] InnoDB: Initializing buffer pool, size = 128.0M
Apr 21 16:55:47 ynh mysqld[27663]: 2019-04-21 16:55:47 3063290672 [Note] InnoDB: Completed initialization of buffer pool
Apr 21 16:55:47 ynh mysqld[27663]: 2019-04-21 16:55:47 3063290672 [Note] InnoDB: Highest supported file format is Barracuda.
Apr 21 16:55:47 ynh mysqld[27663]: 2019-04-21 16:55:47 3063290672 [Note] InnoDB: Starting crash recovery from checkpoint LSN=7469831338
Apr 21 16:55:47 ynh mysqld[27663]: 2019-04-21 16:55:47 3063290672 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
Apr 21 16:55:47 ynh mysqld[27663]: 2019-04-21 16:55:47 3063290672 [Note] InnoDB: Starting final batch to recover 46 pages from redo log
Apr 21 16:55:47 ynh mysqld[27663]: 2019-04-21 16:55:47 3063290672 [ERROR] InnoDB: Trying to access page number 0 in space 537 space name nextcloud/oc_cards_properties, which is outside the tablespace bounds. By$
Apr 21 16:55:47 ynh mysqld[27663]: 2019-04-21 16:55:47 b6961b30 InnoDB: Assertion failure in thread 3063290672 in file ha_innodb.cc line 22057
Apr 21 16:55:47 ynh mysqld[27663]: InnoDB: We intentionally generate a memory trap.
Apr 21 16:55:47 ynh mysqld[27663]: InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
Apr 21 16:55:47 ynh mysqld[27663]: InnoDB: If you get repeated assertion failures or crashes, even
Apr 21 16:55:47 ynh mysqld[27663]: InnoDB: immediately after the mysqld startup, there may be
Apr 21 16:55:47 ynh mysqld[27663]: InnoDB: corruption in the InnoDB tablespace. Please refer to
Apr 21 16:55:47 ynh mysqld[27663]: InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
Apr 21 16:55:47 ynh mysqld[27663]: InnoDB: about forcing recovery.
Apr 21 16:55:47 ynh mysqld[27663]: 190421 16:55:47 [ERROR] mysqld got signal 6 ;
Apr 21 16:55:47 ynh mysqld[27663]: This could be because you hit a bug. It is also possible that this binary
Apr 21 16:55:47 ynh mysqld[27663]: or one of the libraries it was linked against is corrupt, improperly built,
Apr 21 16:55:47 ynh mysqld[27663]: or misconfigured. This error can also be caused by malfunctioning hardware.
Apr 21 16:55:47 ynh mysqld[27663]: To report this bug, see https://mariadb.com/kb/en/reporting-bugs
Apr 21 16:55:47 ynh mysqld[27663]: We will try our best to scrape up some info that will hopefully help
Apr 21 16:55:47 ynh mysqld[27663]: diagnose the problem, but since we have already crashed,
Apr 21 16:55:47 ynh mysqld[27663]: something is definitely wrong and this may fail.
Apr 21 16:55:47 ynh mysqld[27663]: Server version: 10.1.37-MariaDB-0+deb9u1
Apr 21 16:55:47 ynh mysqld[27663]: key_buffer_size=16384
Apr 21 16:55:47 ynh mysqld[27663]: read_buffer_size=262144
Apr 21 16:55:47 ynh mysqld[27663]: max_used_connections=0
Apr 21 16:55:47 ynh mysqld[27663]: max_threads=153
Apr 21 16:55:47 ynh mysqld[27663]: thread_count=0
Apr 21 16:55:47 ynh mysqld[27663]: It is possible that mysqld could use up to
Apr 21 16:55:47 ynh mysqld[27663]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 51025 K bytes of memory
Apr 21 16:55:47 ynh mysqld[27663]: Hope that's ok; if not, decrease some variables in the equation.
Apr 21 16:55:47 ynh mysqld[27663]: Thread pointer: 0x0
Apr 21 16:55:47 ynh mysqld[27663]: Attempting backtrace. You can use the following information to find out
Apr 21 16:55:47 ynh mysqld[27663]: where mysqld died. If you see no messages after this, something went
Apr 21 16:55:47 ynh mysqld[27663]: terribly wrong...
Apr 21 16:55:47 ynh mysqld[27663]: stack_bottom = 0x0 thread_stack 0x20000
Apr 21 16:55:47 ynh mysqld[27663]: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
Apr 21 16:55:47 ynh mysqld[27663]: information that should help you find out what is causing the crash.
Apr 21 16:55:47 ynh systemd[1]: mariadb.service: Main process exited, code=killed, status=6/ABRT
Apr 21 16:55:47 ynh systemd[1]: Failed to start MariaDB 10.1.37 database server.
Apr 21 16:55:47 ynh systemd[1]: mariadb.service: Unit entered failed state.
Apr 21 16:55:47 ynh systemd[1]: mariadb.service: Failed with result 'signal'.
I have looked around for this InnoDB issue, to no avail.
Would you have any idea for what I could do to solve this? Thanks!
