[BUG] Building with Mongo v5 causes issues on older CPU version that don't support AVX

[tristanwilson111]

Describe the bug I do not consider this to be a bug, but a limitation to deploying to older devices. Creating an issue to update both the Synology Wiki page (https://github.com/Tzahi12345/YoutubeDL-Material/wiki/Synology) for reference. In my case, I'm running on the DS920+.

To Reproduce Deploying this project using the default docker-compose.yml on a system with a CPU that does not support AVX will not start MongoDB.

Screenshots

Environment

• YoutubeDL-Material version: Latest & Nightly
• Docker tag: Latest & nightly builds use the latest Mongo version (v5) with the default docker-compose.

Additional context

Re-enabling driver logging on MongoDB allows us to view the reason MongoDB is not starting on older hardware.

This is by design as per MongoDB's article here: https://www.mongodb.com/community/forums/t/mongodb-5-0-cpu-intel-g4650-compatibility/116610

The above link includes a command to build Mongo from source and set a flag to get around the issue, but could cause issues with Mongo v5. I have not attempted this.

I have attached a docker-compose file that will build using the current latest Mongo v4 build.

[tristanwilson111]

docker-compose.txt

[joheiska]

Don't really need to be old CPU for this to happen. Pentium G7400 (alder lake) released in Q1 2022 seems to be the first pentium to have avx support. With celerons the first one to support avx seems to be 6600HE released in Q3 2021.

[tristanwilson111]

@joheiska Good to know. I was just mirroring the verbiage used by MongoDB, but a good call out that this could impact more recent CPUs.

[s-h-a-d-o-w]

Hm, I used your docker compose but even though I've verified that docker actually pulled v4 (see below) , it still prints that warning on startup and nothing is served on 8998. Is there anything I could be missing?

CONTAINER ID   IMAGE                                  COMMAND                  CREATED              STATUS                        PORTS     NAMES
ba77351321b4   tzahi12345/youtubedl-material:latest   "/app/entrypoint.sh …"   About a minute ago   Exited (137) 51 seconds ago             ytdl-ytdl_material-1
fbc11fc274b5   mongo:4                                "docker-entrypoint.s…"   About a minute ago   Exited (0) 46 seconds ago               mongo-db

[tristanwilson111]

@s-h-a-d-o-w, you’ve confirmed it’s still showing by changing logging driver = local instead of none in docker compose? This will show you the error. I wouldn’t expect to see this error in Mongo 4.

[s-h-a-d-o-w]

Well, that's why I'm confused... 😄 I didn't change the logging driver. All Mongo config is exactly like in the file you posted.

[tristanwilson111]

Try commenting out the logging driver setting of "none" like my initial screenshot, and confirm that you see the mongo-db error logged for AVX as shown in my screenshot. Just want to confirm that you're seeing the same AVX error I did. If you're truly seeing the same error I am, it should say MongoDB 5.0+ requires a CPU with AVX support, which shouldn't be the case if you're using my suggested docker compose file specifying mongo:4. I think you may be experiencing a different issue.

Attach a screenshot of the logs if you can

[s-h-a-d-o-w]

[tristanwilson111]

Got it. I tested on my NAS, and found that this error does actually throw in version 4.

This warning, shown above in your screenshot, doesn't actually block the starting of the DB in version 4, it's only informative. Only in v5 is where it will terminate the container.

For myself, when I switched to using the compose above, my containers wouldn't start because of the error "Unable to determine status of lock file in the data directory /data/db: boost::filesystem::status: Permission denied: "/data/db/mongod.lock". Check if your logs contain this.

If they do, try using this compose file instead, which creates a docker volume to get around permission issues.

docker-compose.txt

Otherwise, can you submit your full log file here?

[s-h-a-d-o-w]

Huh. Thanks a lot for trying to help me out but when I just wanted to collect the logs and got distracted for a few minutes, I realized that the frontend actually started!

It was just stuck here, right before pm2 starting, for what seems like 5 minutes:

mongo-db              | {"t":{"$date":"2023-03-28T20:06:11.342+00:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"WTCheckpointThread","msg":"WiredTiger message","attr":{"message":"[1680033971:341949][1:0x7ff3e4bdb700], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 25, snapshot max: 25 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 112"}}
mongo-db              | {"t":{"$date":"2023-03-28T20:07:12.130+00:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"WTCheckpointThread","msg":"WiredTiger message","attr":{"message":"[1680034032:130374][1:0x7ff3e4bdb700], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 27, snapshot max: 27 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 112"}}

On the plus side, maybe your updated compose file will help somebody else stumbling across this. :slightly_smiling_face:

[Tzahi12345]

I updated the docker-compose to be mongo:4 by default, should fix this issue!