search

pulsejet / memories

Fast, modern and advanced photo management suite. Runs as a Nextcloud app.
https://memories.gallery
GNU Affero General Public License v3.0
3.21k stars 87 forks source link

Internal go-vod doesn't start up, but runs fine externally #1046

Open Gnarflord opened 9 months ago

Gnarflord commented 9 months ago

Describe the bug This is all running natively on Arch Linux according to the Arch Wiki

If I set the application to use the internal go-vod transcoder I get a warning message: image If I try to play any media the log just says "Error, memories, Transcode failed: Transcoder returned 408". I can see the running process:

❯ ps aux | grep go-vod
nextclo+ 4071999  0.0  0.0 714528  5504 ?        Sl   11:12   0:00 /tmp/go-vod-oc7qwkgz9ac3-0.2.4-227538c9 /tmp/go-vod/oc7qwkgz9ac3.json

But no go-vod related folders are created in /tmp! I double-checked if the php directive open-basedir limits the folder access of nextcloud but it looks fine:

open_basedir=/var/lib/nextcloud/data:/var/lib/nextcloud/apps:/tmp:/usr/share/webapps/nextcloud:/etc/webapps/nextcloud:\/dev/urandom:/usr/lib/php-legacy/modules:/var/log/nextcloud:/proc/meminfo:/run/redis:/mnt/datengrab/data/nextcloud

The command to test the render pipeline also works correctly:

❯ sudo -u nextcloud \
        ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi \
        -i 'sample.mp4' -vcodec h264_vaapi \
        output-www-data.mp4
ffmpeg version n6.1.1 Copyright (c) 2000-2023 the FFmpeg developers
  built with gcc 13.2.1 (GCC) 20230801
  configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-amf --enable-avisynth --enable-cuda-llvm --enable-lto --enable-fontconfig --enable-frei0r --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libdav1d --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libharfbuzz --enable-libiec61883 --enable-libjack --enable-libjxl --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libplacebo --enable-libpulse --enable-librav1e --enable-librsvg --enable-librubberband --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpl --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-libzimg --enable-nvdec --enable-nvenc --enable-opencl --enable-opengl --enable-shared --enable-vapoursynth --enable-version3 --enable-vulkan
  libavutil      58. 29.100 / 58. 29.100
  libavcodec     60. 31.102 / 60. 31.102
  libavformat    60. 16.100 / 60. 16.100
[...]

The permissions for the render card are set correctly, I've added the user nextcloud to both video and render:

❯ /usr/bin/ls -la /dev/dri
total 0
drwxr-xr-x  3 root root        100 Feb  3 09:53 .
drwxr-xr-x 21 root root       4240 Feb  3 09:53 ..
drwxr-xr-x  2 root root         80 Feb  3 09:53 by-path
crw-rw----  1 root video  226,   1 Feb 15 08:58 card1
crw-rw-rw-  1 root render 226, 128 Feb 15 08:58 renderD128

Now interestingly when I startup go-vod manually as the nextcloud user and setup memories to use an external encoder everything works perfectly:

❯ sudo -u nextcloud /var/lib/nextcloud/apps/memories/bin-ext/go-vod-amd64
2024/02/15 11:11:49 &{Version:0.2.4 Configured:false VersionMonitor:false Bind::47788 FFmpeg:/usr/bin/ffmpeg FFprobe:/usr/bin/ffprobe TempDir:/tmp/go-vod ChunkSize:3 LookBehind:3 GoalBufferMin:1 GoalBufferMax:4 StreamIdleTime:60 ManagerIdleTime:60 QF:0 VAAPI:false VAAPILowPower:false NVENC:false NVENCTemporalAQ:false NVENCScale: UseTranspose:false UseGopSize:false}
2024/02/15 11:11:49 Starting go-vod 0.2.4 on :47788
2024/02/15 11:11:53 &{Version:0.2.4 Configured:true VersionMonitor:false Bind::47788 FFmpeg:/usr/bin/ffmpeg FFprobe:/usr/bin/ffprobe TempDir:/tmp/go-vod ChunkSize:3 LookBehind:3 GoalBufferMin:1 GoalBufferMax:4 StreamIdleTime:60 ManagerIdleTime:60 QF:24 VAAPI:true VAAPILowPower:true NVENC:false NVENCTemporalAQ:false NVENCScale:cuda UseTranspose:false UseGopSize:false}
[...]

I can stream videos without any issues and the appropriate directories are created within /tmp. Why does it matter whether nextcloud or I call the executable?

To Reproduce Install nextcloud according to the arch wiki, setup VAAPI and add the memories app.

Platform:

pulsejet commented 8 months ago

Why does it matter whether nextcloud or I call the executable?

It shouldn't. If the temp directly doesn't exist though, it is likely a permissions issue somewhere.

I also suggest debugging with HW acceleration disabled

joshtrichards commented 7 months ago

open_basedir=/var/lib/nextcloud/data:/var/lib/nextcloud/apps:/tmp:/usr/share/webapps/nextcloud:/etc/webapps/nextcloud:\/dev/urandom:/usr/lib/php-legacy/modules:/var/log/nextcloud:/proc/meminfo:/run/redis:/mnt/datengrab/data/nextcloud

The "not found" for /dev/dri/renderD128 looks like it's because of your open_basedir settings. The file_exists() check fails in PHP since it's not permitted by your configuration.

https://github.com/pulsejet/memories/blob/1918535783947b1114b7b5d165eceebb0a4b0267/lib/Controller/AdminController.php#L166-L170

smirkybg commented 2 months ago

I'm also facing this problem and /dev/dri/renderD128 is indeed in the open_basedir, as required. However, the logs are clearly showing conflicting messages.

==> /var/log/nextcloud/nextcloud.log <==                                                                                                                                                                                                                        
{"reqId":"h2HBsSauX27LeqVSWSLh","level":3,"time":"2024-09-20T07:45:50+00:00","remoteAddr":"194.39.218.10","user":"smirky","app":"PHP","method":"GET","url":"/apps/memories/api/system-status","message":"file_exists(): open_basedir restriction in effect. File
(/dev/dri/renderD128) is not within the allowed path(s): (/var/lib/nextcloud:/tmp:/usr/share/webapps/nextcloud:/etc/webapps/nextcloud:/dev/urandom:/usr/lib/php/modules:/var/log/nextcloud:/proc/meminfo:/proc/cpuinfo:/mnt/hdd-3TB/cloud_storage:/usr/bin:/dev/
dri/renderD128) at /var/lib/nextcloud/apps/memories/lib/Controller/AdminController.php#171","userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36","version":"29.0.7.1","data":{"app":"PH
P"}}  
# ls -l /dev/dri/renderD128
crw-rw-rw- 1 root render 226, 128 Sep 20 10:22 /dev/dri/renderD128
# groups nextcloud
redis render nextcloud

My setup is with NGINX + PHP-FPM.

pulsejet commented 2 months ago

Maybe you need /dev/dri in the basedir restriction instead of the full device path?

smirkybg commented 2 months ago

I tried that too. In fact, I even tried just simply adding the whole root "/" , but it didn't make any difference. I'm not convinced it's open_basedir that is the problem here.