jonashellmann / everydocs-core

A simple Document Management System for private use with basic functionality to organize your documents digitally
GNU General Public License v3.0
209 stars 15 forks source link

Unable to start with Docker Compose. #30

Closed Kimbaras closed 5 months ago

Kimbaras commented 6 months ago

Hi,

I'm trying to deploy the docker-compose stack, but everytime I'm getting a failure with the error in the screenshot error

I've followed the guide here on GitHub, of course editing the various variables (like the mariadb passwords) and editing the everydocs-web-config.js file as described.

Still no luck.

Thanks!

jonashellmann commented 6 months ago

The logs show that there is an unhealthy container during the startup. Since there is only one health check regarding the database (https://github.com/jonashellmann/everydocs-core/blob/master/docker-compose.yaml#L42-L47) it seems that there is some misconfiguration with your database.. The container for Everydocs Core depends on the database to be healthy.

Kimbaras commented 6 months ago

The only things I've changed in the docker-compose are the passwords for the mariadb container (I think).

Later today I will take a look at mine docker-compose and update here.

Thanks

Kimbaras commented 6 months ago

Ok, I don't know what is happening here...

So, right now EveryDocs seems to be running, yet the MariaDB container is flagged "unhealthy" for whichever reason... These are the logs of the mariadb container

2024-03-20 19:02:05 0 [Note] Starting MariaDB 11.3.2-MariaDB-1:11.3.2+maria~ubu2204 source revision 068a6819eb63bcb01fdfa037c9bf3bf63c33ee42 as process 1 2024-03-20 19:02:05 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 2024-03-20 19:02:05 0 [Note] InnoDB: Number of transaction pools: 1 2024-03-20 19:02:05 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions 2024-03-20 19:02:05 0 [Note] mariadbd: O_TMPFILE is not supported on /tmp (disabling future attempts) 2024-03-20 19:02:05 0 [Note] InnoDB: Using liburing 2024-03-20 19:02:05 0 [Note] InnoDB: Initializing buffer pool, total size = 128.000MiB, chunk size = 2.000MiB 2024-03-20 19:02:05 0 [Note] InnoDB: Completed initialization of buffer pool 2024-03-20 19:02:05 0 [Note] InnoDB: File system buffers for log disabled (block size=512 bytes) 2024-03-20 19:02:05 0 [Note] InnoDB: End of log at LSN=47763 2024-03-20 19:02:05 0 [Note] InnoDB: Opened 3 undo tablespaces 2024-03-20 19:02:05 0 [Note] InnoDB: 128 rollback segments in 3 undo tablespaces are active. 2024-03-20 19:02:05 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ... 2024-03-20 19:02:05 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB. 2024-03-20 19:02:05 0 [Note] InnoDB: log sequence number 47763; transaction id 14 2024-03-20 19:02:05 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool 2024-03-20 19:02:05 0 [Note] Plugin 'FEEDBACK' is disabled. 2024-03-20 19:02:05 0 [Note] Plugin 'wsrep-provider' is disabled. 2024-03-20 19:02:05 0 [Note] InnoDB: Buffer pool(s) load completed at 240320 19:02:05 2024-03-20 19:02:05 0 [Note] Server socket created on IP: '0.0.0.0'. 2024-03-20 19:02:05 0 [Note] Server socket created on IP: '::'. 2024-03-20 19:02:05 0 [Note] mariadbd: Event Scheduler: Loaded 0 events 2024-03-20 19:02:05 0 [Note] mariadbd: ready for connections. Version: '11.3.2-MariaDB-1:11.3.2+maria~ubu2204' socket: '/run/mysqld/mysqld.sock' port: 3306 mariadb.org binary distribution

To me seems fine? I will play a bit with it in the next hours / days and I'll report back, but this seems an issue with either the mariadb container or the healthcheck.

Thanks

akshat1 commented 6 months ago

I ran into the same issue and made some progress. The mariadb container is running, but the health check fails, which causes docker to not start the everydocs-core container.

  1. I discovered the actual healthcheck failure by running docker inspect --format "{{json .State.Health }}" mariadb_db_1 | jq '.Log[].Output' (thanks StackOverflow). Replace mariadb_db_1 with your container name.
  2. I noticed that mysqladmin was missing. I found that mysqladmin has been removed from the mariadb image.
  3. I eventually arrived at https://mariadb.org/mariadb-server-docker-official-images-healthcheck-without-mysqladmin/ which provided an alternative health check.

Now my mariadb container is healthy and I'm able to proceed further. However, everydocs_core exits with the following message

Check the Rails upgrade guide at https://guides.rubyonrails.org/upgrading_ruby_on_rails.html#new-activesupport-cache-serialization-format
for more information on how to upgrade.
 (called from <top (required)> at /usr/src/app/config/environment.rb:5)
rake aborted!
TypeError: no implicit conversion of Integer into String
/usr/local/bundle/gems/activerecord-7.1.3.2/lib/active_record/migration.rb:1611:in `crc32'
/usr/local/bundle/gems/activerecord-7.1.3.2/lib/active_record/migration.rb:1611:in `generate_migrator_advisory_lock_id'
/usr/local/bundle/gems/activerecord-7.1.3.2/lib/active_record/migration.rb:1595:in `with_advisory_lock'
/usr/local/bundle/gems/activerecord-7.1.3.2/lib/active_record/migration.rb:1448:in `migrate'
/usr/local/bundle/gems/activerecord-7.1.3.2/lib/active_record/migration.rb:1274:in `up'
/usr/local/bundle/gems/activerecord-7.1.3.2/lib/active_record/migration.rb:1249:in `migrate'
/usr/local/bundle/gems/activerecord-7.1.3.2/lib/active_record/tasks/database_tasks.rb:243:in `migrate'
/usr/local/bundle/gems/activerecord-7.1.3.2/lib/active_record/railties/databases.rake:93:in `block (2 levels) in <top (required)>'
/usr/local/bundle/gems/rake-13.1.0/exe/rake:27:in `<top (required)>'
Tasks: TOP => db:migrate
(See full trace by running task with --trace)

I suspect that the issues are being caused by the mariadb version, going to try and downgrade to an older version.

As an aside, I have been previously burnt by breaking changes between major DB releases. I avoid using :latest for databases now.

jonashellmann commented 6 months ago

@akshat1 Thanks for pointing that out! For my own instance I'm using mariadb:10.7.3. And I just saw that I don't have a healthcheck on the database container or dependencys between the containers as well. Maybe you can try that version and see if it's running? If so, I'm trying to update the docker-compose.yml file soon and might also look deeper into getting compatible with the latest version of MariaDB..

akshat1 commented 6 months ago

Glad to help. I'll try to do it tomorrow night and report back on how it goes.

Kimbaras commented 6 months ago

Hi both,

Thanks for the suggestion, I can confirm I was able to start it correctly while specifying mariadb:10.7.3 as DB container. Was able to create an account and use the interface. I noticed a little issue (not sure if it's user error of what, but I'll open a dedicate issue for that).

On this, from what I can tell, using MariaDB 10.7.3 is working correctly, not sure if you want to keep this one open in order to update the docs or make it work with :latest.

Thanks for the support!

akshat1 commented 6 months ago

Sorry it took me a while to make another attempt. mariadb:10 works 👍🏽. The db container comes up and stays healthy, and the core container is able to start up now.

I have a problem with the web container now but that's a separate issue. Going to spend some time trying to diagnose it before I log an issue.

everydocs_web_1   | standard_init_linux.go:228: exec user process caused: no such file or directory
jonashellmann commented 5 months ago

@Kimbaras I'm glad I was able to help! 😄 I made the change to the docker-compose file in #33. Therefore I'm closing this issue. @akshat1 Feel free to open a new issue with the problem you mentioned. This is the first result when googling the error message: https://stackoverflow.com/a/52665687