March 13, 20188 yr 6 hours ago, marduk201 said: hey anyone got mysql working ? i can't change the password and i cant get root to login.. anyone having the same problem? Never used the official mySQL container (which is what Bungy's template is for), but have used both lsio's MariaDB (its a faster and leaner fork of mySQL) with no issues whatsoever. But, assuming that you've previously had this working, then you're probably best hitting the mySQL forums itself for that issue.
March 25, 20188 yr Is it possible to rename the postgresql docker that the gitlab docker depends on to be postgresql-gitlab? It seems to be set up fairly specifically for use with gitlab, and I'd like to have another postgresql docker for general use. Obviously, having the generic name on the app-specific image is confusing. I tried renaming the docker, but then the gitlab docker couldn't see it. (Would be even nicer if postgresql and redis were just incorporated in the gitlab-ce docker, as it keeps the place tidy — but I guess there's a reason it's done this way…)
April 18, 20188 yr Does anyone have a long-term solution to this problem where the container refuses to stay running? I've found a temporary solution, but an update wipes this out, https://oplatform.club/t/topic/50 Image attached shows logging details of the failure to startup.
April 27, 20188 yr I must have captured a version of GitLab that had this short-lived defect. An update to the image corrected this behavior... yuck!
May 7, 20188 yr Quick question I see that simple machines forums requires SQL has anyone tried to run a web forum from unRAID using this?
June 8, 20188 yr Author Just now, Katherine said: NZBGet 20 is out.https://nzbget.net/history-latest I saw that. I'll push an update to the docker container soon.
June 8, 20188 yr Thank you, @Bungy Can you also include the following modules? py2-requests-oauthlib py2-markdown py2-decorator These are for Subliminal. Edited June 8, 20188 yr by Katherine
June 8, 20188 yr Author The new NZBGet hasn't hit the archlinux repo yet: https://archive.archlinux.org/packages/n/nzbget/ Once it gets in there, I'll trigger a rebuild and get NZBget updated. I'll also try to include those packages. I'm not sure what their equivalents are in archlinux.
June 8, 20188 yr Author @Katherine In the meantime, try out this Dockerfile for adding in those packages: FROM jshridha/docker-nzbgetvpn:latest RUN pacman -S python2-requests-oauthlib python-requests-oauthlib \ python2-markdown python-markdown \ python2-decorator python-decorator That should get you the dependencies into python2 and python3 that you requested. Good luck and feel free to ping me if you notice nzbget get into archlinux's package manager. I don't always do the best job of keeping a close eye on those
June 14, 20188 yr Author @Katherine I pushed a build that bumps nzbget to v20.0, updates the baseimage, and adds in the packages you need. With the updated baseimage, the setup for the VPN has changed. Please check the docs for setup info. It may take 10 minutes or so for the build to finish.
June 14, 20188 yr 16 hours ago, Bungy said: I pushed a build that bumps nzbget to v20.0, updates the baseimage, and adds in the packages you need. With the updated baseimage, the setup for the VPN has changed. Please check the docs for setup info. It may take 10 minutes or so for the build to finish. So my docker won't start. I'm not sure what changes or docs you are referring to. Can you point me in the right direction? Edited June 14, 20188 yr by ulic
June 14, 20188 yr Author 4 hours ago, ulic said: So my docker won't start. I'm not sure what changes or docs you are referring to. Can you point me in the right direction? Please check the documentation located here: https://github.com/jshridha/docker-nzbgetvpn If you can't figure out what to change, please post back and I'll try to help.
June 24, 20188 yr How is it possible to downgrade this docker to latest 5 Version? I'm having issues with mysql V8.
June 24, 20188 yr Author 2 minutes ago, Dave-Kay said: How is it possible to downgrade this docker to latest 5 Version? I'm having issues with mysql V8. Yes, change the image to mysql:5 instead of mysql
June 24, 20188 yr 18 minutes ago, Bungy said: Yes, change the image to mysql:5 instead of mysql while that worked like a charm i'm now unable to start it message is Quote Jun 24 16:33:45 UNRAID kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth31e4db6: link becomes ready Jun 24 16:33:45 UNRAID kernel: docker0: port 2(veth31e4db6) entered blocking state Jun 24 16:33:45 UNRAID kernel: docker0: port 2(veth31e4db6) entered forwarding state Jun 24 16:33:46 UNRAID kernel: docker0: port 2(veth31e4db6) entered disabled state Jun 24 16:33:46 UNRAID kernel: veth7da8719: renamed from eth0 Jun 24 16:33:47 UNRAID kernel: docker0: port 2(veth31e4db6) entered disabled state Jun 24 16:33:47 UNRAID kernel: device veth31e4db6 left promiscuous mode Jun 24 16:33:47 UNRAID kernel: docker0: port 2(veth31e4db6) entered disabled state Edited June 24, 20188 yr by Dave-Kay
June 24, 20188 yr Author 6 minutes ago, Dave-Kay said: while that worked like a charm i'm now unable to start it message is Can you grab the logs from the docker container? something along the lines of this should work, you just may have to change "mysql" to your container name docker logs mysql
June 24, 20188 yr that won't work, since the container is unable to start it seems, the command returns "no such container" docker ps shows the other ones but not mysql oh, wait now it works Edited June 24, 20188 yr by Dave-Kay
June 24, 20188 yr docker logs mysql 2018-06-24T14:49:35.857053Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details). 2018-06-24T14:49:35.859380Z 0 [Note] mysqld (mysqld 5.7.22) starting as process 1 ... 2018-06-24T14:49:35.866733Z 0 [Note] InnoDB: PUNCH HOLE support available 2018-06-24T14:49:35.866771Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2018-06-24T14:49:35.866783Z 0 [Note] InnoDB: Uses event mutexes 2018-06-24T14:49:35.866794Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier 2018-06-24T14:49:35.866805Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.3 2018-06-24T14:49:35.866817Z 0 [Note] InnoDB: Using Linux native AIO 2018-06-24T14:49:35.867388Z 0 [Note] InnoDB: Number of pools: 1 2018-06-24T14:49:35.868236Z 0 [Note] InnoDB: Using CPU crc32 instructions 2018-06-24T14:49:35.871443Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M 2018-06-24T14:49:35.893420Z 0 [Note] InnoDB: Completed initialization of buffer pool 2018-06-24T14:49:35.897308Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority(). 2018-06-24T14:49:35.914911Z 0 [ERROR] [FATAL] InnoDB: Table flags are 0 in the data dictionary but the flags in file ./ibdata1 are 0x4000! 2018-06-24 16:49:35 0x1482ac8ef740 InnoDB: Assertion failure in thread 22551473354560 in file ut0ut.cc line 942 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 14:49:35 UTC - mysqld got signal 6 ; 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. Attempting to collect some information that could help diagnose the problem. As this is a crash and something is definitely wrong, the information collection process might fail. key_buffer_size=8388608 read_buffer_size=131072 max_used_connections=0 max_threads=151 thread_count=0 connection_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68195 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 = 0 thread_stack 0x40000 mysqld(my_print_stacktrace+0x2c)[0x55fbef4f11ec] mysqld(handle_fatal_signal+0x479)[0x55fbeee1fe59] /lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x1482ac4cd0c0] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x1482aac59fff] /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x1482aac5b42a] mysqld(+0x628387)[0x55fbeedf6387] mysqld(_ZN2ib5fatalD1Ev+0x12d)[0x55fbef6bfc8d] mysqld(+0xf9ead1)[0x55fbef76cad1] mysqld(+0xf9f108)[0x55fbef76d108] mysqld(_Z6fil_ioRK9IORequestbRK9page_id_tRK11page_size_tmmPvS8_+0x2b0)[0x55fbef776230] mysqld(_Z13buf_read_pageRK9page_id_tRK11page_size_t+0xce)[0x55fbef72b1ee] mysqld(_Z16buf_page_get_genRK9page_id_tRK11page_size_tmP11buf_block_tmPKcmP5mtr_tb+0x4aa)[0x55fbef6fa34a] mysqld(_Z31trx_rseg_get_n_undo_tablespacesPm+0x143)[0x55fbef69de23] mysqld(+0x6274fb)[0x55fbeedf54fb] mysqld(_Z34innobase_start_or_create_for_mysqlv+0x2f3d)[0x55fbef66acdd] mysqld(+0xd69f63)[0x55fbef537f63] mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x4f)[0x55fbeee6abff] mysqld(+0xb138e6)[0x55fbef2e18e6] mysqld(_Z40plugin_register_builtin_and_init_core_sePiPPc+0x2f0)[0x55fbef2e4ad0] mysqld(+0x64a566)[0x55fbeee18566] mysqld(_Z11mysqld_mainiPPc+0xc71)[0x55fbeee1a121] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x1482aac472e1] mysqld(_start+0x2a)[0x55fbeee1080a] 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. 2018-06-24T14:49:45.387944Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details). 2018-06-24T14:49:45.391051Z 0 [Note] mysqld (mysqld 5.7.22) starting as process 1 ... 2018-06-24T14:49:45.398206Z 0 [Note] InnoDB: PUNCH HOLE support available 2018-06-24T14:49:45.398247Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2018-06-24T14:49:45.398259Z 0 [Note] InnoDB: Uses event mutexes 2018-06-24T14:49:45.398270Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier 2018-06-24T14:49:45.398286Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.3 2018-06-24T14:49:45.398296Z 0 [Note] InnoDB: Using Linux native AIO 2018-06-24T14:49:45.398867Z 0 [Note] InnoDB: Number of pools: 1 2018-06-24T14:49:45.399062Z 0 [Note] InnoDB: Using CPU crc32 instructions 2018-06-24T14:49:45.402126Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M 2018-06-24T14:49:45.423700Z 0 [Note] InnoDB: Completed initialization of buffer pool 2018-06-24T14:49:45.427567Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority(). 2018-06-24T14:49:45.440538Z 0 [ERROR] [FATAL] InnoDB: Table flags are 0 in the data dictionary but the flags in file ./ibdata1 are 0x4000! 2018-06-24 16:49:45 0x1480c3218740 InnoDB: Assertion failure in thread 22543262123840 in file ut0ut.cc line 942 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 14:49:45 UTC - mysqld got signal 6 ; 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. Attempting to collect some information that could help diagnose the problem. As this is a crash and something is definitely wrong, the information collection process might fail. key_buffer_size=8388608 read_buffer_size=131072 max_used_connections=0 max_threads=151 thread_count=0 connection_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68195 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 = 0 thread_stack 0x40000 mysqld(my_print_stacktrace+0x2c)[0x55760de621ec] mysqld(handle_fatal_signal+0x479)[0x55760d790e59] /lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x1480c2df60c0] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x1480c1582fff] /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x1480c158442a] mysqld(+0x628387)[0x55760d767387] mysqld(_ZN2ib5fatalD1Ev+0x12d)[0x55760e030c8d] mysqld(+0xf9ead1)[0x55760e0ddad1] mysqld(+0xf9f108)[0x55760e0de108] mysqld(_Z6fil_ioRK9IORequestbRK9page_id_tRK11page_size_tmmPvS8_+0x2b0)[0x55760e0e7230] mysqld(_Z13buf_read_pageRK9page_id_tRK11page_size_t+0xce)[0x55760e09c1ee] mysqld(_Z16buf_page_get_genRK9page_id_tRK11page_size_tmP11buf_block_tmPKcmP5mtr_tb+0x4aa)[0x55760e06b34a] mysqld(_Z31trx_rseg_get_n_undo_tablespacesPm+0x143)[0x55760e00ee23] mysqld(+0x6274fb)[0x55760d7664fb] mysqld(_Z34innobase_start_or_create_for_mysqlv+0x2f3d)[0x55760dfdbcdd] mysqld(+0xd69f63)[0x55760dea8f63] mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x4f)[0x55760d7dbbff] mysqld(+0xb138e6)[0x55760dc528e6] mysqld(_Z40plugin_register_builtin_and_init_core_sePiPPc+0x2f0)[0x55760dc55ad0] mysqld(+0x64a566)[0x55760d789566] mysqld(_Z11mysqld_mainiPPc+0xc71)[0x55760d78b121] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x1480c15702e1] mysqld(_start+0x2a)[0x55760d78180a] 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.
June 24, 20188 yr going back to V8 works btw. the container starts immediately. it seems that V8 made a change, which needs to be reverted manually?
June 24, 20188 yr Author Do you have backups of your appdata by any chance? Otherwise you may be forced to backup using mysql workbench under v8 and then restoring that data into v5
June 24, 20188 yr Author Also, can I ask what issue you're having with v8? It may be easiest to address those issues directly.
June 24, 20188 yr 46 minutes ago, Bungy said: Do you have backups of your appdata by any chance? Otherwise you may be forced to backup using mysql workbench under v8 and then restoring that data into v5 it's a pretty fuckup around here... the user i connected with is now reported to be not able to login at V8. it sais "he's a definer" and i lost root-pw and i tried mysql -p root but that gives back an error that root is not allowed to do that... so i don't need much, but there are 2 databases i would like to save. there should be an older backup of appdata, around 3 weeks ago... is it possible to just overwrite appdata in the folder mysql and everything will be restored from a few weeks ago? Quote Also, can I ask what issue you're having with v8? It may be easiest to address those issues directly. Kodi Alpha 18 is not connecting to the database anymore. I'm quite sure it started with upgrade to V8 Edited June 24, 20188 yr by Dave-Kay
June 24, 20188 yr Author Yes, you can restore the appdata from 3 weeks ago and it'll revert your data back to that point. You'll just need to restore the mysql appdata. Without a user or root password, that's probably your only bet. If you have a user password, you should be able to backup the databases that user has access to. Yeah v8 has caused issues with some other apps I've used. In those cases, there was small fixes that I needed to do to get it to work, but restoring appdata will be the easiest way to get you back up and running.
June 24, 20188 yr 2 minutes ago, Bungy said: Yes, you can restore the appdata from 3 weeks ago and it'll revert your data back to that point. You'll just need to restore the mysql appdata. Without a user or root password, that's probably your only bet. If you have a user password, you should be able to backup the databases that user has access to. Yeah v8 has caused issues with some other apps I've used. In those cases, there was small fixes that I needed to do to get it to work, but restoring appdata will be the easiest way to get you back up and running. so the was to do it would be, stop mysql docker, delete mysql appdate, restore the old data and fire it up again? else, when i try to access from docker console an put in mysql -u root it tells me ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES) is it in any way possible to get root account to work (again)?
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.