Closed MorgothSauron closed 3 years ago
I'm not able to reproduce on amd64
$ docker-compose up -d
Creating network "root_default" with the default driver
Creating volume "root_db" with default driver
Creating nextcloud-db ... done
[ERROR] mysqld got signal 4
How are the resources on your system? Especially considering it's an arm64 device is the memory getting maxed out triggering an OOMkill?
I don't see any message in dmesg
that would indicate that OOMkill happens.
This is a Pi4 with 4Gb of RAM. Right now it's only running a PiHole and Unbound, each using less than 1% of memory. There is nothing else running.
Hello,
I got the very same issue, also with a Pi 4 4GB. So it may be an issue that only occurs on arm64 ?
I noticed is that it occurred when migrating from 10.4 to 10.5 on an existing database, but also with a fresh database.
I managed to reproduce with 10.5.1 but the issue cannot be reproduced on latest 10.4 (10.4.13 I believe).
Edit:
I ran the basic command:
sudo docker run -e MYSQL_RANDOM_ROOT_PASSWORD=true mariadb
Please find the dump below,
stdout
:
2020-07-20 22:01:03+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2020-07-20 22:01:03+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 1:10.5.4+maria~focal started.
2020-07-20 22:01:03+00:00 [Note] [Entrypoint]: Initializing database files
Installation of system tables failed! Examine the logs in
/var/lib/mysql/ for more information.
The problem could be conflicting information in an external
my.cnf files. You can ignore these by doing:
shell> /usr/bin/mysql_install_db --defaults-file=~/.my.cnf
You can also try to start the mysqld daemon with:
shell> /usr/sbin/mysqld --skip-grant-tables --general-log &
and use the command line tool /usr/bin/mysql
to connect to the mysql database and look at the grant tables:
shell> /usr/bin/mysql -u root mysql
mysql> show tables;
Try 'mysqld --help' if you have problems with paths. Using
--general-log gives you a log in /var/lib/mysql/ that may be helpful.
The latest information about mysql_install_db is available at
https://mariadb.com/kb/en/installing-system-tables-mysql_install_db
You can find the latest source at https://downloads.mariadb.org and
the maria-discuss email list at https://launchpad.net/~maria-discuss
Please check all of the above before submitting a bug report
at https://mariadb.org/jira
stderr
:
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Server version: 10.5.4-MariaDB-1:10.5.4+maria~focal
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467809 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x49000
/usr/sbin/mysqld(my_print_stacktrace+0x30)[0xaaaad1e0b310]
Printing to addr2line failed
/usr/sbin/mysqld(handle_fatal_signal+0x45c)[0xaaaad18b69bc]
linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0xffffa2d915b0]
/usr/sbin/mysqld(crc32c_aarch64+0x4b4)[0xaaaad1e22adc]
/usr/sbin/mysqld(+0xcf68ec)[0xaaaad1cea8ec]
/usr/sbin/mysqld(+0xcf7274)[0xaaaad1ceb274]
/usr/sbin/mysqld(+0xcf8fa8)[0xaaaad1cecfa8]
/usr/sbin/mysqld(+0xcf9f50)[0xaaaad1cedf50]
/usr/sbin/mysqld(+0xcfb198)[0xaaaad1cef198]
/usr/sbin/mysqld(+0x6090f0)[0xaaaad15fd0f0]
/usr/sbin/mysqld(+0xb67cc8)[0xaaaad1b5bcc8]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x6c)[0xaaaad18b97f4]
/usr/sbin/mysqld(+0x7057dc)[0xaaaad16f97dc]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0x864)[0xaaaad16fa8b4]
/usr/sbin/mysqld(+0x63f270)[0xaaaad1633270]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x40c)[0xaaaad1638adc]
/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0xe8)[0xffffa241f090]
/usr/sbin/mysqld(+0x639d90)[0xaaaad162dd90]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
Writing a core file...
Working directory at /var/lib/mysql
Resource Limits:
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size unlimited unlimited bytes
Max resident set unlimited unlimited bytes
Max processes unlimited unlimited processes
Max open files 1048576 1048576 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 14780 14780 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
Core pattern: |/usr/share/apport/apport %p %s %c %d %P %E
Illegal instruction (core dumped)
I tried version 10.4.13 with the same docker-compose
file on the same pi4 and it is working.
nextcloud-db | 2020-07-21 18:42:38+02:00 [Note] [Entrypoint]: Database files initialized
nextcloud-db | 2020-07-21 18:42:38+02:00 [Note] [Entrypoint]: Starting temporary server
nextcloud-db | 2020-07-21 18:42:38+02:00 [Note] [Entrypoint]: Waiting for server startup
nextcloud-db | 2020-07-21 18:42:38 0 [Note] mysqld (mysqld 10.4.13-MariaDB-1:10.4.13+maria~focal-log) starting as process 124 ...
nextcloud-db | 2020-07-21 18:42:38 0 [Warning] The parameter innodb_large_prefix is deprecated and has no effect. It may be removed in future releases. See https://mariadb.com/kb/en/library/xtradbinnodb-file-format/
nextcloud-db | 2020-07-21 18:42:38 0 [Note] InnoDB: Using Linux native AIO
nextcloud-db | 2020-07-21 18:42:38 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
nextcloud-db | 2020-07-21 18:42:38 0 [Note] InnoDB: Uses event mutexes
nextcloud-db | 2020-07-21 18:42:38 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
nextcloud-db | 2020-07-21 18:42:38 0 [Note] InnoDB: Number of pools: 1
nextcloud-db | 2020-07-21 18:42:38 0 [Note] InnoDB: Using generic crc32 instructions
nextcloud-db | 2020-07-21 18:42:38 0 [Note] mysqld: O_TMPFILE is not supported on /tmp (disabling future attempts)
nextcloud-db | 2020-07-21 18:42:38 0 [Note] InnoDB: Initializing buffer pool, total size = 256M, instances = 1, chunk size = 128M
nextcloud-db | 2020-07-21 18:42:38 0 [Note] InnoDB: Completed initialization of buffer pool
nextcloud-db | 2020-07-21 18:42:38 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
nextcloud-db | 2020-07-21 18:42:38 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
nextcloud-db | 2020-07-21 18:42:38 0 [Note] InnoDB: Creating shared tablespace for temporary tables
nextcloud-db | 2020-07-21 18:42:38 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
nextcloud-db | 2020-07-21 18:42:38 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
nextcloud-db | 2020-07-21 18:42:38 0 [Note] InnoDB: Waiting for purge to start
nextcloud-db | 2020-07-21 18:42:38 0 [Note] InnoDB: 10.4.13 started; log sequence number 60972; transaction id 21
nextcloud-db | 2020-07-21 18:42:38 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
nextcloud-db | 2020-07-21 18:42:38 0 [Note] Plugin 'FEEDBACK' is disabled.
nextcloud-db | 2020-07-21 18:42:38 0 [Note] InnoDB: Buffer pool(s) load completed at 200721 18:42:38
nextcloud-db | 2020-07-21 18:42:38 0 [Warning] 'user' entry 'root@8ebd26088651' ignored in --skip-name-resolve mode.
nextcloud-db | 2020-07-21 18:42:38 0 [Warning] 'user' entry '@8ebd26088651' ignored in --skip-name-resolve mode.
nextcloud-db | 2020-07-21 18:42:38 0 [Warning] 'proxies_priv' entry '@% root@8ebd26088651' ignored in --skip-name-resolve mode.
nextcloud-db | 2020-07-21 18:42:38 0 [Note] Reading of all Master_info entries succeeded
nextcloud-db | 2020-07-21 18:42:38 0 [Note] Added new Master_info '' to hash table
nextcloud-db | 2020-07-21 18:42:38 0 [Note] mysqld: ready for connections.
nextcloud-db | Version: '10.4.13-MariaDB-1:10.4.13+maria~focal-log' socket: '/var/run/mysqld/mysqld.sock' port: 0 mariadb.org binary distribution
nextcloud-db | 2020-07-21 18:42:39+02:00 [Note] [Entrypoint]: Temporary server started.
Hello,
I have also an error message because of anything with InnoDB:
[ERROR] InnoDB: Corrupted page [page id: space=0, page number=0] of datafile './ibdata1' could not be found in the doublewrite buffer.
My System: Odroid C2 (arm64), Debian Buster.
Parts of my docker-compose.yml:
version: "3" services: [..] db: container_name: mariadb image: arm64v8/mariadb:latest restart: always environment: MYSQL_ROOT_PASSWORD: "" MYSQL_DATABASE: "" MYSQL_USER: "" MYSQL_PASSWORD: "" volumes:
- ./data/mysql:/var/lib/mysql
- /etc/localtime:/etc/localtime:ro networks: nginx-proxy-manager_default: ipv4_address: 172.224.1.255 [..] volumes: [..] db:
networks: nginx-proxy-manager_default: ipam: driver: default config:
- subnet: 172.224.0.0/16
My error-log (from 'docker logs mariadb'):
2020-07-24 20:50:00+02:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 1:10.5.4+maria~focal started. 2020-07-24 20:50:01+02:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql' 2020-07-24 20:50:01+02:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 1:10.5.4+maria~focal started. 2020-07-24 20:50:01+02:00 [Note] [Entrypoint]: Initializing database files 2020-07-24 20:50:01 0 [ERROR] InnoDB: Corrupted page [page id: space=0, page number=0] of datafile './ibdata1' could not be found in the doublewrite buffer. 2020-07-24 20:50:01 0 [ERROR] InnoDB: Plugin initialization aborted with error Data structure corruption 2020-07-24 20:50:02 0 [ERROR] Plugin 'InnoDB' init function returned error. 2020-07-24 20:50:02 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 2020-07-24 20:50:02 0 [ERROR] Unknown/unsupported storage engine: InnoDB 2020-07-24 20:50:02 0 [ERROR] Aborting
Installation of system tables failed! Examine the logs in /var/lib/mysql/ for more information.
The problem could be conflicting information in an external my.cnf files. You can ignore these by doing:
shell> /usr/bin/mysql_install_db --defaults-file=~/.my.cnf
You can also try to start the mysqld daemon with:
shell> /usr/sbin/mysqld --skip-grant-tables --general-log &
and use the command line tool /usr/bin/mysql to connect to the mysql database and look at the grant tables:
shell> /usr/bin/mysql -u root mysql mysql> show tables;
Try 'mysqld --help' if you have problems with paths. Using --general-log gives you a log in /var/lib/mysql/ that may be helpful.
The latest information about mysql_install_db is available at https://mariadb.com/kb/en/installing-system-tables-mysql_install_db You can find the latest source at https://downloads.mariadb.org and the maria-discuss email list at https://launchpad.net/~maria-discuss
Please check all of the above before submitting a bug report at https://mariadb.org/jira
May someone know a solution for this?
Mathias
definitely broke on arm64. going down to 10.4.x or lower solves all issues
It looks like this problem was originally introduced by MariaDB/server@0928596a8bd54c3ec85462eb4993464eac19f8f2 in MariaDB 10.5.0. We are probably missing some run-time check.
@MorgothSauron Can you run following code snippet and share the output
using namespace std;
int main() { cout << "is CRC32 support (HWCAP_CRC32) " << ((getauxval(AT_HWCAP) & HWCAP_CRC32) ? "true" : "false") << endl; cout << "is PMULL support (HWCAP_PMULL) " << ((getauxval(AT_HWCAP) & HWCAP_PMULL) ? "true" : "false") << endl; }
Hi @mysqlonarm ,
I tested your script on my platform which is exactly the same as @MorgothSauron . Please find the output below:
is CRC32 support (HWCAP_CRC32) true is PMULL support (HWCAP_PMULL) false
Hope it helps
Thanks @alexandresoro. That explains. So we will have to add runtime check for said instruction too.
@alexandresoro Can you also share the output of lscpu. What I am wondering is PI4 has cortex a-72 processor that should technically has pmull support so wanted to re-validate what lscpu report.
Sure, please find it below:
❯ lscpu alex@pi 0.14 13% 2.78G 17:40:34 Architecture: aarch64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 Vendor ID: ARM Model: 3 Model name: Cortex-A72 Stepping: r0p3 CPU max MHz: 1500.0000 CPU min MHz: 600.0000 BogoMIPS: 108.00 Vulnerability Itlb multihit: Not affected Vulnerability L1tf: Not affected Vulnerability Mds: Not affected Vulnerability Meltdown: Not affected Vulnerability Spec store bypass: Vulnerable Vulnerability Spectre v1: Mitigation; __user pointer sa nitization Vulnerability Spectre v2: Vulnerable Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Not affected Flags: fp asimd evtstrm crc32 cpuid
Let me know if this is enough, I have limited access to it right now, but I could check later on if needed.
Thanks @alexandresoro. This should be fine. so the said model is confirmed to have crc32 support w/o pmull support.
This looks to be indeed something that is not mandatory on armv8 architecture if this comment is still valid:
https://github.com/google/crc32c/pull/6#issuecomment-328713398
I just checked 10.5.5 which includes the fix for ARM CPUs having crc32 but missing pmull, and it works again like a charm.
Thanks for fixing this one!
MDEV-23030 fixed in 10.5.5
After I long pause I resumed the building of a nextcloud instance. When I start the container I get the following error using the same docker-compose file as before. It's a new installation: the database doesn't exist yet.
My docker-compose:
docker version