Fail to compile mediasoup fuzzer due to liburing

[ibc]

When running make fuzzer in Docker in macOS:

Downloading liburing source from https://github.com/axboe/liburing/archive/refs/tags/liburing-2.4.tar.gz
Downloading file of unknown size.

meson.build:284:20: ERROR: failed to unpack archive with error: [Errno 40] Too many levels of symbolic links: '/mediasoup/worker/subprojects/liburing-liburing-2.4/man/io_uring_check_version.3'

I'm "fixing" it in an unrelated PR by adding this in Dockerfile:

ENV MESON_ARGS="-Dms_disable_liburing=true"

But obviously this is not a solution.

[jmillan]

This is a bug in a python module used by meson when untar-ing the file. It detects self a pointing link, which is a bug in the module.

I have no idea why it does happen in Docker and not in a non dockered linux.

[nazar-pc]

Why does it even try to copy those files in the first place? Those filed should be downloaded inside of container instead.

[ibc]

Why does it even try to copy those files in the first place? Those filed should be downloaded inside of container instead.

What do you mean? This happens when running make or make fuzzer or make test (or invoke xxx) within the Docker container.

[nazar-pc]

I mean it might be that worker/out and worker/subprojects are copied into the container, but they should not be.

[ibc]

See Dockerfile. It doesn't copy anything but mounts a volume on the mediasoup root folder. The goal is to be able to keep editing original mediasoup source code in your editor while running/testing stuff in Docker.

Said that, it's needed (and I always do) to clean everything in the worker (make clean-subprojects, make clean-pip, make clean-all) once in Docker, otherwise tons of arch issues due to already instaled pip, meson and subprojects. And doing it doesn't avoid this issue.

[nazar-pc]

That is what I'm saying, it should probably only mount source code, but not the rest. So instead of mounting the whole root, it should strategically mount only specific things where there are no symlinks. All the downloaded stuff should be inside of the container only.

[ibc]

How would you tell Docker to mount this tree?

mediasoup/node/
mediasoup/rust/
mediasoup/worker/src
mediasoup/worker/include
mediasoup/worker/subprojects/ BUT ONLY .wrap files
mediasoup/worker/fuzzer
mediasoup/worker/test
mediasoup/worker/meson...etc

in the same "mediasoup" folder destination without including mediasoup/worker/subprojects?

[ibc]

Anyway I insist:

The scenario of the bug is that we run "make docker" then "make docker-run" to enter the Docker container, then clean absolutely everything in the worker folder including subprojects. Then "make" and it fails. So it wouldn't be fixed by not mounting worker/subprojects folder.

[nazar-pc]

The goal of what I was describing is to make sure container works with local (to container) file system, not with paths mounted from the host. If that is achieved, it will not fail anymore.

[ibc]

The goal of what I was describing is to make sure container works with local (to container) file system, not with paths mounted from the host. If that is achieved, it will not fail anymore.

Right now the whole mediasoup folder is mounted in the container. Assuming that we must manually clear worker artifacts once in Docker, what's exactly wrong with that?

And if we do your approach (which involves copying source files to the container) we loose the ability to edit those source files direclty in our editor and work normally. That's a huge drawback I couldn't accept. I run Docker, enter it, run make fuzzer and run fuzzer stuff. Something fails. I want to edit files in my editor then make fuzzer and run fuzzer stuff again rather than having to edit with Vi the source files in the Docker container.

[nazar-pc]

If this is just for fuzzer, then you probably don't need node or rust in there and you can copy *.wrap files, while mounting worker/fuzzer, worker/src and similar strategic directories only.

[ibc]

I do run Node as well when in Docker, I don't remember what for but I've done.

[jmillan]

The only solution I find here is to simply add the MESON_ARGS="-Dms_disable_liburing=true" env variable to the Dockerfile.

This error comes from the fact that MacOS FS is case insensitive and linux is not. There are ways to make a Docker volume case sensitive in MacOS but I honestly don't think it's worth it.

If we ever need to try liburing in Docker, then we know we need to use a local folder, rather than one from the MacOS host.

[ibc]

Is then ok if I write a PR disabling liburing in our Dockerfiles? However we loose the ability to run mediasoup with liburing in Linux Docker in our Macs.

[jmillan]

However we loose the ability to run mediasoup with liburing in Linux Docker in our Macs.

You can only loose something you have :-)

Edit: and liburing cannot be run in Docker from MacOS right now.

[ibc]

Edit: and liburing cannot be run in Docker from MacOS right now.

But it's fetched anyway... and I don't remember why because the Docker Linux kernel in which mediasoup is built is the same than the Docker Linux kernel in which it runs later.

[ibc]

I'm fixing this issue in https://github.com/versatica/mediasoup/pull/1338 as a bonus track.

[ibc]

As Jose told me, here is the obvious problem in case insensitive file systems: https://github.com/axboe/liburing/tree/master/man

[ibc]

BTW the bug is reported in liburing but response fro authors is "use a decent case sensitive filesystem".

[ibc]

Solution in macOS:

1. Assuming you have mediasoup in /Users/xxx/src/mediasoup.
2. cs $HOME
3. mkdir src-cs (cs == case sensitive), or name it as you wish.
4. sudo diskutil apfs addVolume disk1 APFSX src-cs -mountpoint /Users/xxx/src-cs
5. sudo chown -R $(id -u):$(id -g) src-cs (ignore the errors).
6. Now clean worker and pip and out/ and subprojects in your mediasoup folder.
7. cp -a /Users/xxx/src/mediasoup /Users/xxx/src-cs/mediasoup
8. Done.

Now you have mediasoup in a case insensitive file system and make fuzzer works in Docker Linux.

then change soft links in mediasoup-demo, etc.

[ibc]

It's trivial so I'm gonna remove the hack from Dockerfiles.