Container mongo Started - Error response from daemon on kernel 7.0.13

[philipk99]

I tried installing the newest version on my Fedora 44 with kernel 7.0.13. I know there is a issue (#322) with the almost same name and description but i think those are two separate problems.

Steps to Reproduce

Using:

1. bin/up
   Initiating Mongo replica set...
   [+] up 1/1
   ✔ Container mongo Started
   Error response from daemon: Container <container_id> is restarting, wait until the container is running

2. bin/start
   [+] start 1/1
   ✘ Container mongo Error dependency mongo failed to start
   dependency failed to start: container mongo is unhealthy

Analysis

The logs from mongodb container:
MongoDB cannot start: Linux kernel versions 6.19 and newer has a known incompatibility with this version of MongoDB. See https://jira.mongodb.org/browse/SERVER-121912 for more information.

Solution

I've found this post (https://www.mongodb.com/community/forums/t/mongodb-8-x-and-linux-kernel-6-19/337547) on the mongodb forum indicating the fix for the issue is upgrading to version 8.0.4.

I've tried and tested it a little and it looks like it works.

[Firefox2100]

Hello, I encountered the same issue after updating the host kernel. However, I think the current 8.0 tag on mongodb actually resolve to latest 8.0 release, which is 8.0.29 (particularly 376f5173003b hash). Pinning it to 8.0.4 likely downgrades it, which I'm not sure is safe. Another workaround is to add to config/docker-compose.override.yml:

services:
  mongo:
    environment:
      GLIBC_TUNABLES: glibc.pthread.rseq=1

This makes it use glibc's rseq instead of Google's problematic one, letting MongoDB start. It works on my system without pinning the MongoDB version.

[philipk99]

Hello @Firefox2100, you are absolutely right to point out that my method was actually a downgrade. I have therefore closed my PR.

To further iterate on the matter, as mentioned in the MongoDB 8.0 Release Notes, this error should only apply to kernel versions 6.19 through 7.0.13. The upcoming MongoDB 8.0.30 release should clear all remaining errors (mainly this).

Because of that, I agree that your method is the best workaround for these version combinations right now. I think it makes sense to stick with your approach and wait for the 8.0.30 release to see if the issue is fully resolved.