New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with Docker db images on Windows 10 Home #55

Open
mstenta opened this Issue Feb 28, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@mstenta
Member

mstenta commented Feb 28, 2018

Steve tried to get farmOS up and running on Windows 10 Home using Docker Toolbox, and ran into an issue with the MariaDB image:

Creating farmos_db_1  ... done
Creating farmos_db_1  ...
Creating farmos_www_1 ... done
Attaching to farmos_db_1, farmos_www_1
db_1   | Initializing database
www_1  | farmOS not detected. Building...
db_1   | 2018-02-28  3:40:37 140158690969472 [Warning] InnoDB: Failed to set O_DIRECT on file./ibdata1;CREATE: Invalid argument, ccontinuing anyway. O_DIRECT is known to result in 'Invalid argument' on Linux on tmpfs, see MySQL Bug#26662.
db_1   | 2018-02-28  3:40:44 140158690969472 [ERROR] InnoDB: Operating system error number 22 in a file operation.
db_1   | 2018-02-28  3:40:44 140158690969472 [ERROR] InnoDB: Error number 22 means 'Invalid argument'
db_1   | 2018-02-28  3:40:44 140158690969472 [ERROR] InnoDB: File ./ib_logfile101: 'aio write' returned OS error 222. Cannot continue operation
db_1   | 180228  3:40:44 [ERROR] mysqld got signal 6 ;
db_1   | This could be because you hit a bug. It is also possible that this binary
db_1   | or one of the libraries it was linked against is corrupt, improperly built,
db_1   | or misconfigured. This error can also be caused by malfunctioning hardware.
db_1   |
db_1   | To report this bug, see https://mariadb.com/kb/en/reporting-bugs
db_1   |
db_1   | We will try our best to scrape up some info that will hopefully help
db_1   | diagnose the problem, but since we have already crashed,
db_1   | something is definitely wrong and this may fail.
db_1   |
db_1   | Server version: 10.2.13-MariaDB-10.2.13+maria~jessie
db_1   | key_buffer_size=134217728
db_1   | read_buffer_size=2097152
db_1   | max_used_connections=0
db_1   | max_threads=102
db_1   | thread_count=0
db_1   | It is possible that mysqld could use up to
db_1   | key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 759916 K  bytes of memory
db_1   | Hope that's ok; if not, decrease some variables in the equation.
db_1   |
db_1   | Thread pointer: 0x0
db_1   | Attempting backtrace. You can use the following information to find out
db_1   | where mysqld died. If you see no messages after this, something went
db_1   | terribly wrong...
db_1   | stack_bottom = 0x0 thread_stack 0x49000
db_1   | /usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x555829812b3e]
db_1   | /usr/sbin/mysqld(handle_fatal_signal+0x345)[0x55582928f3e5]
db_1   | /lib/x86_64-linux-gnu/libpthread.so.0(+0xf890)[0x7f793cbad890]
db_1   | /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f793af38067]
db_1   | /lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f793af39448]
db_1   | /usr/sbin/mysqld(+0x888456)[0x555829490456]
db_1   | /usr/sbin/mysqld(+0x88ee46)[0x555829496e46]
db_1   | /usr/sbin/mysqld(+0xa2ff4b)[0x555829637f4b]
db_1   | /usr/sbin/mysqld(+0x86c12f)[0x55582947412f]
db_1   | /usr/sbin/mysqld(+0x86d022)[0x555829475022]
db_1   | /usr/sbin/mysqld(+0x86d89d)[0x55582947589d]
db_1   | /usr/sbin/mysqld(+0x87370a)[0x55582947b70a]
db_1   | /usr/sbin/mysqld(+0x41fb8a)[0x555829027b8a]
db_1   | /usr/sbin/mysqld(+0x92b06d)[0x55582953306d]
db_1   | /usr/sbin/mysqld(+0x80de69)[0x555829415e69]
db_1   | /usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x64)[0x555829291734]
db_1   | /usr/sbin/mysqld(+0x4ee665)[0x5558290f6665]
db_1   | /usr/sbin/mysqld(_Z11plugin_initPiPPci+0x8aa)[0x5558290f7d7a]
db_1   | /usr/sbin/mysqld(+0x44113e)[0x55582904913e]
db_1   | /usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x65e)[0x55582904e6be]
db_1   | /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f793af24b45]
db_1   | /usr/sbin/mysqld(+0x43925d)[0x55582904125d]
db_1   | The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
db_1   | information that should help you find out what is causing the crash.
db_1   | Aborted
db_1   |
db_1   | Installation of system tables failed!  Examine the logs in
db_1   | /var/lib/mysql/ for more information.
db_1   |
db_1   | The problem could be conflicting information in an external
db_1   | my.cnf files. You can ignore these by doing:
db_1   |
db_1   |     shell> /usr/bin/mysql_install_db --defaults-file=~/.my.cnf
db_1   |
db_1   | You can also try to start the mysqld daemon with:
db_1   |
db_1   |     shell> /usr/sbin/mysqld --skip-grant-tables --general-log &
db_1   |
db_1   | and use the command line tool /usr/bin/mysql
db_1   | to connect to the mysql database and look at the grant tables:
db_1   |
db_1   |     shell> /usr/bin/mysql -u root mysql
db_1   |     mysql> show tables;
db_1   |
db_1   | Try 'mysqld --help' if you have problems with paths. Using
db_1   | --general-log gives you a log in /var/lib/mysql/ that may be helpful.
db_1   |
db_1   | The latest information about mysql_install_db is available at
db_1   | https://mariadb.com/kb/en/installing-system-tables-mysql_install_db
db_1   | You can find the latest source at https://downloads.mariadb.org and
db_1   | the maria-discuss email list at https://launchpad.net/~maria-discuss
db_1   |
db_1   | Please check all of the above before submitting a bug report
db_1   | at http://mariadb.org/jira
db_1   |
www_1  | Cloning into '/var/farmOS'...
www_1  | Beginning to build /var/farmOS/build-farm.make.                             [ok]
farmos_db_1 exited with code 1

It appears that this is the important line:

db_1 | 2018-02-28 3:40:37 140158690969472 [Warning] InnoDB: Failed to set O_DIRECT on file./ibdata1;CREATE: Invalid argument, ccontinuing anyway. O_DIRECT is known to result in 'Invalid argument' on Linux on tmpfs, see MySQL Bug#26662.

Searching for that brought me to: docker-library/mariadb#38

According to that issue, it sounds like there's an issue with the MariaDB 10.1 issue.

@mstenta

This comment has been minimized.

Member

mstenta commented Feb 28, 2018

Tried changing image: mariadb:latest to image: mysql:latest in the docker-compose.yml and the following error came up instead:

b_1   | Initializing database
www_1  | farmOS not detected. Building...
db_1   | 2018-02-28T15:00:57.663562Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
db_1   | 2018-02-28T15:00:57.673686Z 0 [Warning] Setting lower_case_table_names=2 because file system for /var/lib/mysql/ is case insensitive
db_1   | 2018-02-28T15:00:59.919721Z 0 [ERROR] InnoDB: Operating system error number 22 in a file operation.
db_1   | 2018-02-28T15:00:59.920267Z 0 [ERROR] InnoDB: Error number 22 means 'Invalid argument'
db_1   | 2018-02-28T15:00:59.920622Z 0 [ERROR] InnoDB: File ./ib_logfile101: 'aio write' returned OS error 122. Cannot continue operation
db_1   | 2018-02-28T15:00:59.920991Z 0 [ERROR] InnoDB: Cannot continue operation.
farmos_db_1 exited with code 3

@mstenta mstenta changed the title from Issue with Docker MariaDB on Windows to Issues with Docker db images on Windows 10 Home Feb 28, 2018

@mstenta

This comment has been minimized.

@mstenta

This comment has been minimized.

Member

mstenta commented Feb 28, 2018

Workaround for the MySQL issue:

In docker-compose.yml add the following volume to the db service:

- './.data/conf:/etc/mysql/conf.d'

Then, in the .data folder, add a folder called conf, with a file called local.cnf, with the following content:

[mysqld]
innodb_use_native_aio=0

(This also assumes that you made the change to docker-compose.yml described in the earlier comment: #55 (comment))

change image: mariadb:latest to image: mysql:latest in the docker-compose.yml

Then run sudo docker-compose up.

@strarsis

This comment has been minimized.

strarsis commented Apr 26, 2018

@mstenta: I tried this on WSL/Docker Toolbox but it seems to just ignore the options.
I also tried to set the options via CLI:
command: mysqld --innodb-flush-method=O_DSYNC --innodb-use-native-aio=OFF --log_bin=ON

On startup for initial database creation:

[Warning] InnoDB: Failed to set O_DIRECT on file./ibdata1;CREATE: Invalid argument
[ERROR] InnoDB: File ./ib_logfile101: 'aio write' returned OS error 222. Cannot continue operation

So O_DIRECT and aio are still used despite the settings, it seems to be simply ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment