adamrehn / pixel-streaming-linux

Issue tracker repository for Pixel Streaming for Linux
https://adamrehn.com/articles/pixel-streaming-in-linux-containers/
22 stars 7 forks source link

Unable to start container "Signal 11 caught" #25

Closed avg07 closed 3 years ago

avg07 commented 3 years ago

I have issue after packaging project from ue-4.23.1 and run image:

FROM adamrehn/ue4-full:4.23.1-pixelstreaming AS builder
COPY --chown=ue4:ue4 ./DummyProject /tmp/project
WORKDIR /tmp/project
RUN ue4 package
FROM adamrehn/ue4-runtime:latest
COPY --from=builder --chown=ue4:ue4 /tmp/project/dist/LinuxNoEditor /home/ue4/project
ENV NVIDIA_DRIVER_CAPABILITIES ${NVIDIA_DRIVER_CAPABILITIES},video
RUN ln -s /usr/lib/x86_64-linux-gnu/libnvidia-encode.so.1 /home/ue4/project/DummyProject/Binaries/Linux/libnvidia-encode.so.1

I'm trying to docker-run like this: sudo docker run --network=host --gpus=all -v /tmp/.X11-unix:/tmp/.X11-unix:rw -e DISPLAY ue4-test:13 bash -c "/home/ue4/project/MyProject3.sh -PixelStreamingIP=localhost -PixelStreamingPort=8888 -opengl4"

But recive error:

sh: 1: xdg-user-dir: not found
error: XDG_RUNTIME_DIR not set in the environment.
Unable to read VR Path Registry from /home/ue4/.config/openvr/openvrpaths.vrpath
Unable to read VR Path Registry from /home/ue4/.config/openvr/openvrpaths.vrpath
Checking Pak Config
Signal 11 caught.
Malloc Size=65538 LargeMemoryPoolOffset=65554 
Malloc Size=65535 LargeMemoryPoolOffset=131119 
Malloc Size=123824 LargeMemoryPoolOffset=254960 
4.23.1-8386587+++UE4+Release-4.23 517 0
Disabling core dumps.
CommonUnixCrashHandler: Signal=11
Engine crash handling finished; re-raising signal 11 for the default handler. Good bye.
Segmentation fault (core dumped)
xxEoD2242 commented 3 years ago

Hey @avg07, can I ask what the value of $DISPLAY is?

Also, just looking at your docker run, I see a couple of things:

  1. -e DISPLAY should be -e "DISPLAY:$DISPLAY". The reason for this is that you have to access the environment variable with a $.
  2. You need --runtime=nividia unless followed the directions to set the nvidia runtime as default for your Docker containers.

From the errors, what's happening is that the display isn't set correctly so Unreal thinks that there is no display. Unreal gets very upset with that. If fixing the display doesn't work, I'd take a look at rendering offscreen.

avg07 commented 3 years ago

Hey @xxEoD2242, thanks fo reply. Maybe I passed DISPLAY variable incorrectly, but problem is enother. When I removed run-parameters -PixelStreamingIP=localhost -PixelStreamingPort=8888 everything worked. But now another problem - quality of streamed picture is very bad.

adamrehn commented 3 years ago

@xxEoD2242 thanks for helping out. For the sake of others reading this thread in the future I'll just quickly point out that there are very minor inaccuracies in both of the list items from your comment:

  1. The syntax -e DISPLAY is actually equivalent to -e "DISPLAY=$DISPLAY", since the default behaviour when no value is specified is to propagate the value of the environment variable from the host system. Your suggested colon-delimited syntax of -e "DISPLAY:$DISPLAY" is actually invalid and will not propagate anything, since unlike the flags for bind-mounting, the -e flag expects an equals sign as the delimiter. (See the relevant section of the docker run reference for details.)

  2. The --runtime=nvidia flag is only recommended when using NVIDIA Docker version 2.x. When using newer versions of the NVIDIA Container Toolkit with Docker 19.03 or newer, the preferred flag is --gpus=all, as used in the original poster's code. The older flag will still work if you've installed the nvidia-container-runtime package for backwards-compatibility though. (See NVIDIA's Architecture Overview of the NVIDIA Container Toolkit for details.)

@avg07 it sounds like you've managed to resolve your segmentation fault crash. With regards to the quality of the streamed video, there are some known bugs in older versions of Pixel Streaming that can result in stream quality degradation over time. I'd recommend migrating to the newly-released 4.25 version of Pixel Streaming for Linux and seeing if that gives better results. If the video quality is still poor under 4.25 then please open a separate issue to discuss that.

avg07 commented 3 years ago

@adamrehn, thanks fo reply. Yes, I was able to run pixel-streaming on 4.23 version. As about the quality, I solved the problem by adding the -NvEncFrameRateNum = 1 parameter. Now I working on 4.25 version. Thanks!